What we are going to learn?
- How to identify, exploit, and remediate the top web security vulnerabilities, as well as much more arcane bugs.
- How to properly handles cryptography.
- How to design and review applications from a security standpoint
- How to operate as a bug bounty hunter or a security consultant
- Much cooler stuff
Note: Brush up your web request skills with your language of choice. If using Python ‘requests’ package is my personal favorite.
Link to Official Python Requests documentation
Burp proxy ( free edition is perfectly fine)
This allows you to watch all HTTP(S) communication, intercept and modify requests, and replay existing requests
You will use this constantly in both your coursework and exams
Firefox allows you to set proxy settings specified in the browser, rather than setting them system-wide
This will be your friend when you’re testing, to isolate an application
1.You’re here to learn how to break things before anyone else does so that vulnerabilities can be fixed before attackers get them.
1.1 To do that, you need to understand how attackers operate, what their goals are, and how they think.
2The most important tenet of the breaker mindset is this: pushing a button is the most effective way to discover what it does.
2.1 If you don’t understand what an application is doing and why it’s doing it, you’re going to have a hard time finding ways to break it.
3. Prioritizing your efforts is crucial to ensure that where there are still bugs, the impact will be relatively low. Making an accurate assessment of high-risk areas is critical.
4. When assessing an application, find every bit of functionality you can. Once you have a rough list of all of the bits of application, consider this: If I was an attacker, what would my goal be?
For each vulnerability include the following:
- Title — E.g. “Reflected Cross-Site Scripting in profiles”
- Description — Brief description of what the vulnerability is
- Reproduction Steps — Brief description of how to reproduce the bug; preferably with a small proof of concept
- Impact — What can be done with the vulnerability?
- Mitigation — How is it fixed?
- Affected Assets — Generally a list of affected URLs.
This is handled differently just about everywhere, but I recommend basing severity on the difficulty of exploitation and potential business impact.
- Informational — issue has no real impact
- Low — The business impact is minimal
- Medium — Potential to cause harm to users, but not revealing data
- High — Potential to reveal user data or aids in the exploitation of other vulnerabilities
- Critical — Hig risk of personal/confidential data exposure, general sys compromise, and another severe impact to the business.
Let us see an example
Can you find what’s wrong with the code… It’s your first bug
The code is pretty straightforward:
- Was a ‘name’ parameter passed via GET? if so, print ‘Hello <name>!’ in an h1 tag.
- Print a form for the user to enter their name
What could possibly go wrong with such a simple piece of code?
What would happen if you were to go to this page?
The HTML would then be: <h1>Hello<script>alert(1);</script>!</h1>
What you’ve just seen is an example of reflected cross-site scripting.