1) First, intercept the GET request and then click on Action button. In the menu, select ‘Do intercept’ > ‘Response to this request’.
2) Click Forward to allow the GET request to be made. Then you will notice that you can now see the response from www.example.com
4) Finally, when you forward the edited response, the alert will appear and the body will show that it is tampered.
In this challenge, you will notice that the application is checking for a valid email address. Once the input is validated as an email, it will use the input as part of a query. Because of this weak defence, once we managed to bypass the email validator, we will be able to perform SQL injection attacks.
The main obstacle is to form an input which is both a valid email and contains malicious value. Let’s use the hint to see how the query looks like.
For a valid email, there should not be any space in between the value. Hence the usual SQLi payload “something’ OR 1=1–” does not work here. The work around is to use || instead of ‘OR’.
If you look at the POST request, there is a parameter “userData”. We can try to brute-force the values in the parameter to see if we can access the data from admin perspective.
trying this, we will find that this brute-force does not help much as other
userData values are invalid. So we need to rethink our strategy. Let’s look at
the source-code now to see if we can observe any useful information.
In this snippet code, we can see that there is a submission form that is for a normal user and an admin account. Looking carefully, we can see the URL is different.
Change the URL of the POST request to the URL found in the admin account submission form and we can see that the result key will appear.
I recommend this book to learn about product development from a software engineer and designer who had worked on various important products in Apple such as Safari browser and iPhone. Below are my key takeaways from the books:
Demo served as the primary means to turn ideas into software.
This push for simplicity had a purpose. Even though he was a high-tech CEO, Steve could put himself in the shoes of customers, people who cared nothing for the ins and outs of the software industry. He never wanted Apple software to overload people, especially when they might already be stretched by the bustle of their everyday life.
Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them.
Demos were fundamental to our work at Apple. We used them to highlight the potential, explore the concepts, show the progress, prompt the discussion, and drive the decisions for making our products. I started to understand how demos could play all these roles in creative and technical work when I was surprised by a single brilliant demo during my first few weeks at Apple, a moment that gave me my first real view into how the company made its software.
Chief among our missteps was failing to conceive of our software as a single product instead of as a set of separate projects. We never figured out how to integrate the pieces.
Over time, Don and I began to understand and absorb the model Richard showed us. Look for ways to make quick progress. Watch for project stalls that might indicate the lack of potential. Cut corners to skip unnecessary effort. Remove distractions to focus attention where it needs to be. Start approximating your end goal as soon as possible. Maximize the impact of your most difficult effort. Combine inspiration, decisiveness, and craft to make your demos.
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
It represented an important technical insights: When software behavior is mysterious, get more organized.
People matter more than programming.
Steve said: “I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”
Every major feature on the iPhone started as a demo, and for a demo to be useful for us, it had to be concrete and specific. We need concrete and specific demos to guide our work, since even an unsophisticated idea is hard to discuss constructively without an artifact to illustrate it.
The point is that concrete and specific examples make the difference between a discussion that is difficult, perhaps impossible, to have and one that feels like child’s play.
We rarely had a brainstorming session.
If brainstorms run longer than an hour or so, or if there are more than a handful of people in attendance, or if they’re a common occurrence, they can devolve into a form of sneaky procrastination. Whiteboard discussions feel like work, but often they’re not. It’s difficult to talk productively about ideas in the abstract.
Literally, we couldn’t get away with telling. We were required to show. We combined some inspiration, craft, taste, and decisiveness, and we shared our results. We had to work like this, because the team didn’t accept anything unless it is concrete and specific, and a demo showing what we meant. Then we tried out each other’s demos, said what we liked and what we didn’t, and offered suggestions for improvements, which led to more demos and more feedbacks.
Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positives ones. It couldn’t be an even trade-off either. Great products make people happy almost all the time and do the opposite rarely, if at all.
Empathy is a crucial part of making great products.
As a creative and technical practitioner, I couldn’t open myself to an infinite regress of ideas at every step of accomplishing a task. It’s important to keep making progress and to keep sight of priorities. That doesn’t give product designers the license to ignore philosophy. Rather, in my case, I recognized that I’m not a philosopher myself; I’m closer to a carpenter. As a maker of products, I always turned less to the theoretical and more to the applied.
A lack of specific thoughts isn’t a big deal when picking fruits to put on top of breakfast cereal, but such gaps are an issue in creative work. Persist too long in making choices without justifying the, and an entire creative effort might wander aimlessly. The results might be the sum of wishy-washy half decisions.
Building trust in a personal refined-like response takes time and practice. It also requires a measuring stick. Studying great work from the past provides the means of comparison and contrast and lets us tap into the collective creativity of previous generations.
The past is a source of the timeless and enduring. This is where Kant returns to the discussion, and this notion suggests how his philosophy might figure into creative work. I can use Kant , but only if I know about him, and only to the extent that I’ve internalized what he said and what it means to me.
The same goes for the whole scope of creative achievement, from the paintings of Frida Kahlo, the blues music of the Reverend Gary Davis, the theories of Charles Darwin, the philosophy of Lao Tzu, the software optimization ideas of Donald Knuth, or the beliefs and practices of the ancient Greek visitors to the Delphic Oracle. When I study the past, I make a point of deciding what I like, and sometimes this build-up catalog of refined-like response about past works finds a suitable outlet and a natural expression in my present-day work.
We used the word ‘heuristics’ to describe aspects of software development that tip toward the liberal arts. Its counterpart, “algorithm”, was its alter ego on the technical side. Heuristics and algorithms are like two sides of the same coin. Both are specific procedures for making software do what it does, taking input, applying an operation, and producing output. Yet each had a different purpose.
Algorithms produce quantifiable results, where progress is defined by measurements moving in a predetermined direction, as in the case of the nearly yearlong effort to improve the performance of Safari.
Heuristics also have a measurement or value associated with them – the duration for an animation or the red-green-blue values for an onscreen colour, but there isn’t a similar “arrow of improvement” that always points the same way. Unlike evaluating algorithms, heuristics are harder to nail down.
Algorithms and heuristics must coordinate to make a great high-tech product.
When we got an idea, we cobbled together a first cut on the algorithms and heuristics we would need to illustrate it. Then we pulled together the supporting resources – code, graphics, animations, sounds, icons and more – to produce a demo. After we showed the demo and shared some feedback with each other, we made decisions about changes that might be an improvement. Many times this came down to tuning some heuristics, or modifying how an algorithm and heuristic combined. Whatever it was, the concrete and specific modifications we chose to make led to the actions items that justified making the next demo. Repeat, then repeat again. Doing this over and over again set out projects on the slow path to accumulating positive change. This is how we started with an idea and finished with software for a product.
I’d like to end with a note to readers at the beginning of their careers. You might be telling yourself that you want a career in product development. You may have plans to do great things in some other fields. Either way, I have some advice: Get busy. Decide what it means to do great work, and then try to make it happen. Success is never assured, and the effort might not be easy, but if you love what you’re doing, it won’t seem so hard.
There weren’t any company handbooks describing these elements. Nobody outlined this list in a new-employee orientation. This list was distilled from the everyday work at Apple.
Inspiration: Thinking big ideas and imaging what might be possible
Collaboration: Working together well with other people and seeking to combine your complementary strengths
Craft: Applying skill to achieve high-quality results and always striving to do better.
Diligence: Doing the necessary grunt work and never resorting to shortcuts and half measures.
Decisiveness: Making tough choices and refusing to delay or procrastinate.
Taste: Developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole.
Empathy: Trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs.
Before performing source code review, you should get some hands-on experience with developing an iOS application. In this post, I will show you some of the possible steps to get started. You will spend roughly 30 hours on developing some iOS applications and learning some of the common libraries in Swift 5.
Now it is time to write some code. The purpose of this exercise is to understand the basic structure of an iOS application such as: – Learn how to link UI objects (e.g. UIImage, Buttons, Sliders etc.) in the Main Board to the View Controller – Learn how the function in the ViewController can update the UI objects values. – Naming UI objects – Uploading images into Assets.xcassets directory – Learn to initialise variables in Swift. – Differentiate between ‘var’ and ‘let’ declaration (var is used to initialise the mutables while let is used for declaring constant)
Build an intermediate iOS application – 8 hours
Build an application which stores data locally. The types of data should also include sensitive data such as username and password.
Purpose of UserDefaults. The data is saved as plist. This is not a database. Just use it to learn small kb of data and not for large amount of data.
Data Storage Methods: 1. UserDefaults 2. Encode Data into plists 3. Keychain (An API to store sensitive data (e.g. username, password etc.) securely 4. SQLite 5. Core Data (Object Oriented Database) 6. Realm
Build another intermediate iOS application – 12 hours
<Draft version> The purpose of this blog series is to help an Application Security engineer to learn enough about iOS application security in order to perform source code review. The posts will also require hands-on testing as this will increase understanding of the vulnerabilities.
iOS Application Security
iOS Hacker’s Handbook
Advanced Apple Debugging & Reverse Engineering
Mac OS X and iOS Internals
Volume I: User Mode (v1.3)
Volume II: Kernel Mode
Volume III: Security & Insecurity
The Mobile Application Hacker’s Handbook
OWASP Mobile Application Security Verification Standards (MASVS)