Reconnaissance

You have to ask yourself where, what and how in that order.

  • Where is the vulnerability?
  • What is the vulnerability?
  • How is the vulnerability exploitable?

0. Prequisites

I can use DevTools

Before continuing, can you use DevTools properly?

I have a goal in mind

What exactly are you trying to achieve here? Is it getting admin rights? Is it getting a shell? Is it a simple information leak? Are we trying to inject new users?

1. "Where": The Attack Surface

Introduction

Check out OWASP

OWASP has released a bunch of great resources.
For example, I took this list from them. You might be interested in this too.

Obviously if there's no way to interact with an application (i.e., a black box) then there's nothing to exploit. We have to identify possible places where a vulnerability could be hiding. Some specific points of entry are listed below. Be sure to keep track of:

  1. User interface (UI) forms and fields
  2. HTTP headers and cookies
  3. APIs
  4. Files/Other local storage
  5. Databases
  6. Email or other kinds of messages

You may want to group the elements above into different types, such as:

  1. Login/authentication entry points
  2. Admin interfaces
  3. Inquiries and search functions
  4. Data entry (CRUD) forms
  5. Transactional interfaces/APIs
  6. Operational command and monitoring interfaces/APIs
  7. Interfaces with other applications/systems

From OWASP's "Attack Surface Analysis Cheat Sheet"

For web apps you can use a tool like the OWASP ZAP or Arachni or Skipfish or w3af or one of the many commercial dynamic testing and vulnerability scanning tools or services to crawl your app and map the parts of the application that are accessible over the web.

Once you've made your list of common entry points, you should determine how the website interacts with it. Examples are given below.

Examples

Here are some examples and some possible questions you can ask yourself!

  • A login is a possible attack surface. How does the website log you in? How are your credentials sent to the website? Is it through an HTTP POST request? What is being sent? Are there any hidden values being sent?

    Tip

    You can investigate further through capturing Network Requests using DevTools!

    Pro Tip

    Sometimes websites will send more data than you give it. These are usually in the form of <hidden> fields.

  • Cookies can be a possible attack surface. What cookies are being sent? What information do the cookies encode/represent? Are the cookies encrypted? How are the cookies encrypted? Why are the cookies being sent?

    Tip

    Be sure to check common encodings such as Base64, JWT or even AES!

    Warning

    Sometimes, cookies can be misleading! Be sure to ignore cookies starting with GA_ as those are Google Analytics cookies.

  • Data entry forms are a possible attack surface. Where and how is the data being sent? Can you see the data after? How is the data being displayed after being entered into the system?

    Where does data go after? Can you see it?

    What does a SQL insert statement look like?

    SQL is not the only thing out there! Ever heard of Flask?

  • HTTP Requests are a possible attack surface. Are there any query parameters being sent? Are there any in the URL? Look out for things such as id=1 lang=en file=index etc...

2. "What": Common Vulnerabilities

Vulnerability Signs to look out for
SQLi -