Are you wanting to break into InfoSec (Information Security) but you aren't sure where to start? If web applications, red teaming, or pentesting (The latter two are out of scope for this post - but I think the fundamentals here are important) sounds up your alley then hopefully this word spaghetti will be useful for you!
Who am I
At the time of writing I am a Practice Manager for Leviathan Security Group. My role largely involves training up new consultants for web and mobile application security, as well as get them started on the road to being pentesters (if they so desire). If I'm not doing that I'm hacking stuff: From mobile operating systems to thick client apps to (predominantly) web applications. I've been hacking for most of my life - though nowadays I focus on iOS/MacOS/Android/browsers in my spare time.
Caveats
While I am going to talk about what worked for me and people who I have mentored, it doesn't mean it's going to work for you. That's ok! We all learn in different ways, the important thing is to take what you can use, discard the rest, and hopefully pass that knowledge onto someone else who thinks more like you! Passing on that knowledge is key to helping lift other people up into the industry.
I am also a massive nerd who LOVES hacking stuff. I would do it for fun - I'm incredibly lucky to have been born in a time when the thing I love to do pays super well. If you're here to just get a check - I respect that - this is a fantastic way to do it (I would argue there are better ways but this is definitely one of the more fun ones IMO :D).
Finally, I've predominantly been at consulting companies for my day job. I personally enjoy it but it is definitely not for everyone. I would submit that the ability to take a look at a wide range of technologies quickly has helped me a ton, but that is another discussion or post if there's interest.
Why I chose web and think you should too
- No hardware really required besides a laptop, so remote is much easier
- Who doesn't have a website/web app nowadays
This meant as long as I could always reliably find web bugs and keep myself up to date on the latest techniques, I'd have a job! In my book this is a good thing. Some people might say that web is a lot more boring or not as cool as finding memory corruption vulnerabilities, but ignore the haters because they're wrong :). We need people who do both to protect users, their data, and companies.
Before we get started, we need to set some goals
Don't just take my word for it - read this kick ass blog post by Azeria here. It's a great methodology for how to help you help yourself. (Note: if you're interested in binary exploitation, she has other fantastic articles and walkthroughs, all of which are 11/10.)
I suggest having two sets of goals, which we'll break down next.
First set of goals: Learning how to learn for your future
There are a few things required to be really good at finding bugs: Asking "Why", "How", and following this up with digging in to gain an understanding about what you're looking at. For instance, let's say you're looking at SQL injection: Why does the string ' or 1=1--' let you login as an administrative user on the web application you're hacking?
Once you can answer the why (String concatenation being used to construct the query) you then need to be able to answer the how: Not only for how the exploit works, but also how the remediation works as well. For SQL injection - we use parameterized queries, but how do they work, and what do you do when you can't use parameterzied queries? (This is left as an exercise for the reader)
Memorization of facts can be helpful for very junior positions, but eventually a better understanding will be required, and getting the motions down for how you do that is vital to a long and successful career.
Detour: Resources to use
I personally learn best by getting hands on practice, and is usually what I recommend others try as well. here are some free and legal resources:
- Burpsuite(AKA Burp)
- This is THE tool basically everyone uses - it is good to learn the free version as it makes a lot of things easier when you start your first job
- OWASP Top 10
- This is a link to the OWASP Top 10 - a list of the top 10 most common security flaws found in web applications
- Portswigger labs
- This is where you can learn about these different flaws and actively exploit them using your browser and Burp
- Natas - A wargame on OverTheWire
- This is like #3, except it's non guided and a good way to learn and build up your skills and confident
Second set of goals: Learning web
Coming up with your own short term goals is ideal, however here are some to get you started:
- Be comfortable using Burp - intruder + repeater + proxy are the main three
- #3 has tons of guides for this, and you will get practice while doing #3 and #4
- Pick 2-3 items in the OWASP Top Ten and be able to do the following:
- Describe the issue in your own words
- Ex: "SQL Injection occurs when string concatenation is used to construct a SQL query"
- Discuss how you find them
- Ex: "You can search for SQL injection vulnerabilities using special SQL characters, such as ',", and more".
- Discuss how you exploit them
- Ex: "The common academic example of a payload containing SQL injection is '1 OR 1=1--'. More generically, you exploit these type of vulnerabilities by using the user controlled input to modify the SQL query being used by the application"
- Discuss how you remediate them.
- Ex: "Use parameterized queries where possible"
- Getting to level 11 Natas
- This helps you gain more familiarity with Burp, and web apps in general. These first levels largely teach basic concepts, as it's misconfigurations and simple bugs that are doable without burp
- I'd highly recommend not cheating and looking up walkthroughs for any wargames if possible.
- Hints are fine, but in my experience part of the learning experience is figuring it out on your own. This is what usually makes me have that "AHA!" moment, where things finally click together.
Case Study
Recently someone I've been guiding through getting into Infosec was putting some example reports together to show potential companies that he was serious. (Companies looking to hire - I will gladly pass on contact info if you're interested in hiring him).
Here's a snippet from one of his example reports:
 |
| Example report from someone trying to break into infosec |
There are several positives here that are highlighted, and several things that aren't highlighted that are also positive. Let's start with the highlighted positives (In order from top to bottom):
- The vulnerability is ranked with CVSS 3.1
- He took the time to figure out how one bug severity rating system, while providing the data of how he arrived at the numbers (not shown in screenshot).
- Is it super relevant? No but it shows he cared enough to find something that would fit his needs. Sometimes you have to find something "Good enough" for your current task
- The remediation advice is solid for an entry level position
- IMO it is pretty generic, but that's what you'd expect from an entry level applicant
- (Not shown) the images say what he said it says, and do not look photo shopped
- At previous employer, one of our competitors used to photoshop screenshots to use as proof of exploitation. They did not last long.
Other positives:
- Grammar and flow is decent - this is important as we write TONS of reports
- Description explains why the developer should care about the bug: You can login as admin!
Of course, there are some issues with this as well:
- There are steps to reproduce, but you have to somewhat read between the lines. Creating a "Steps to reproduce" section will be helpful for someone to quickly validate you did what you said you did
- There is no demonstrated understanding of the vulnerability
- The report states that there is a SQL injection vulnerability. However, there is no explanation of why the payload works. I can't derive that you understand what SQL injection is by reading this report, which you will want companies to be able to do.
- There is no description of what SQL injection is: The report describes why a developer should care (See #2 above), but doesn't describe what the actual vulnerability is.
Overall, I think with a bit of finessing, making the changes above, and practicing some more on natas or the Portswigger labs he'll be on his way to getting his first infosec job.
Hopefully this is helpful to someone out there - feel free to reach out with other questions / comments and I'll try to help you out!
