So you want to be a security engineer?

Security engineering is different from traditional computer engineering: it requires a different mindset and viewpoint. I can spend hours going into the nuances of why and how, but instead I will point you to this eloquent essay by Parisa Tabriz. I strongly recommend reading it before continuing with the rest of this article. If you are not one for long essays then check out TL;DR by Michal Zalewski (@lcamtuf)

Given that security is a vast space it would be impossible to outline each and every skill that would be helpful for a security engineer to possess, instead I have chosen to focus on a specific area — web application security. Web applications are easily accessible to everyone and require little or no setup time. The ideas outlined here may not translate directly to other areas of security, but should give you an idea of how to break things. Embracing that attacker mindset is crucial to being a good security engineer and understanding what you are protecting against.

Attacker mindset

In security, you can divide people into two categories defenders and attackers. Regardless of the side you choose, they both share the same goal, securing the system — only their path varies.

If you are tasked with designing a system, think about the attack surface, outline the threats to the system and implement controls to mitigate them. On the flip side if you are tasked with breaking the system, the first two steps remain the same — where they diverge is spotting the holes in the controls and exploiting them. The best way to look at this is to “code defensively and explore offensively”.

In order to spot threats it’s important to look at the system through the lens of an attacker, embracing the attacker mindset. It involves training yourself to look beyond the paper clip and and see a lock pick, in other words, using something fairly innocuous for an unintended purpose. When looking at a new system, try to look at it from a different perspective, think about new and ingenious ways to mess with it. This is of course easier said than done, let’s try to put together a plan to cultivate this mindset to identify security vulnerabilities in web applications.

Step 1: Learn the theory

In order to exploit web applications it’s important to have the basics down. A couple of things to get started with:

1. HTML and JS — you need to be able to write a basic web application and to understand the rough workings of an application by glancing at the code
2. Understand concepts like Same Origin Policy, Cross Origin Resource Sharing, Document Object Model
3. Understand how Web cookies work
4. Know about HTTP Requests and Response formats
5. Understand how browsers work — certain implementation specifics around things like rendering, certificate pinning, XSS filters, and so on
6. Web Security guidelines — OWASP Top 10 : list of commonly found web vulnerabilities, MITRE CWE: collection of common software weaknesses, CERT Secure Coding
7. Guidelines: coding standards for C,C++, Java and Perl which will be used in the backend

Books are a great way of deep diving into the theory, “The Web Application Hacker’s Handbook”, “Tangled Web: A guide to securing Modern Web Applications” and “The Browser Hacker’s Handbook” explore the sections outlined above, with the latter two books focusing specifically on browsers.

Step 2: Guided Tutorials

Once the theory is out of the way, you can start applying it. I use the term tutorials loosely here, intentionally vulnerable applications like WebGoat, Gruyere, Mutillidae come with walkthroughs and sections that are explicitly marked for a vulnerability. This shifts the focus from finding a vulnerability to exploiting it. If you get stuck feel free to leverage hints, guides or video walkthroughs, make sure you try to common vulnerabilities and understand why the exploit works.

There are detailed steps on Webgoat’s Wiki to help with the setup. Once you have it setup, you can play try your hand at the XSS labs, the best part is it comes with ample hints and links to solutions to help when you get stuck.

Step 3: Challenges with solutions

Now it’s time to remove the training wheels and dip your toe in some challenges and real world applications.

Xssgame is a series of challenges by Google aimed at teaching users to identify basic XSS bugs. I would recommend playing through all the levels before proceeding to the next step. Don’t be afraid to use the hints if you get stuck.

Step 4 (a): Write some code

Time to shift gears and get your hands dirty with some coding. Grab a friend to make it a pair programming exercise, this will bring different viewpoints and coding patterns to the table. Pick a popular use case (To do list, calendar, etc.) and try to design a web application for it. While developing the application make sure you use popular libraries or boilerplate code (if they have security anti-patterns even better!). This step will help understand common anti-patterns and language specific pitfalls.

Not sure what to implement? How about a simple task manager that,

• Allows users to insert tasks
• Check off tasks
• Search for tasks

In addition to the client side code (HTML, JS) you will need some server side code and a database. You can run these locally or spin up an instance on the cloud. If you want to cut down on start up time and try a simpler use case, you can try out our Web Starter Kit.

Step 4 (b): Break your code

Now that application is up and running, try to break the application, find and exploit the vulnerabilities in it. You might find vulnerabilities introduced by you or the libraries / templates you used.

Step 4 (c ): Fix your code

Given that the application is now broken, time to fix it! Categorize the vulnerabilities into buckets — Design and Implementation, based on when they could have been identified and fixed. Try to address these issues without forgoing functionality or usability. Understanding how to the fix issues will help you become better at spotting flaws or bypassing fixes.

Step 5 (a): Break Applications — Black Box approach

When testing applications, the source code might not always be available. In this case, you will have to work off the data you have at hand, this includes — front end code (HTML, JS), HTTP requests and responses and session identifiers. Using a proxy like Burp or ZAP you can intercept and modify the communication between the client and server. Please remember to only test applications you have explicit permission to test, a good source of such applications are bug bounties. Companies like Google pay researchers money to identify and responsibly disclose security vulnerabilities in their products. This is a great way to get exposed to large scale, real world applications and to gain visibility in the security community.

If you find bug bounties intimidating, you can try your hand at finding vulnerabilities in older applications with known vulnerabilities (can be tracked using CVEs). This is a great way to try your hand at finding the vulnerabilities and exploiting vulnerabilities in real world application while still having the option of looking up advisories or proof of concepts to help you along. OWASP Broken Web Applications (BWA) Virtual Machine has applications for steps 2,3,5 and should help cut down on the setup time substantially.

You can check out Google’s bug bounty program here, platforms like Bugcrowd and Hackerone host the programs of multiple companies. Here is an example of an XSS found by a researcher in Google’s account recovery flow.

Step 5 (b): Break Applications — White Box approach

Now that you have some experience in reviewing code and exploiting vulnerabilities, time to to put that skill to use by looking at some open source application, libraries or plugins. Once you feel confident reviewing applications in a specific language, try switching to a different language. Some of the projects might even outline the overall design, look over it and try to identify design flaws.

Open source applications are a great way to get accustomed to reading code written by other people. Once you find an issue, take a stab at writing a patch for it. Google’s patch rewards program rewards proactive security improvements to select open source applications.

Using these steps, you can learn about vulnerabilities like XSS, why it happens, how to prevent it and how to test for it. You can repeat the steps for different concepts like CSRF, SQL injection and other web vulnerabilities. You can also repeat these steps with advanced XSS concepts likeTemplate injection or CSP bypasses. These steps are meant to provide a framework that transitions from theory to application and helps you understand both — how to spot the issues and how to fix them.

If you’re interested in security and privacy engineering jobs at Google, browse open jobs here: https://goo.gl/k8bomn