How To Write An Application Security Finding


Although most application security testers would prefer to spend their time hunting for the next cool finding, we all know that at some point we have to devote some time to writing up our work. You may have found a severe vulnerability in the application but if you can’t effectively describe the issue to the client, they may not truly understand its impact or how to remediate it and they may end up being in a worse place than when you started.

To be an effective application security tester, you need to be able to clearly communicate your findings in your reports.

Although there isn’t any one formula for writing up application security findings, there are definitely some key points to keep in mind when preparing your finding for the vulnerability report. In general, most finding reports will contain the following sections when describing an application vulnerability:

  • Description
  • Impact and Risk
  • Remediation
  • Evidence
  • References

Description

The description is where you introduce the finding to your readers and provide some background on the issue. You should not assume that consumers of the vulnerability report will understand the finding prior to reading the report. Even though an issue like SQL Injection has been around for many years, there may be readers who have very little real understanding of the issue. The finding description is your chance to educate the reader with a clear explanation of the vulnerability, what causes it, and how it could be exploited. It can even be helpful to provide some history on the finding and cite something like an RFC when writing the description. For instance, here is a description for a finding called SameSite Not Set :

Description
The application uses a cookie that is set without the SameSite flag. The SameSite flag is a browser-based standard introduced by Google in 2016 that instructs browsers to prevent cookies from being sent in cross-site requests. Restricting cookies to their initial origin mitigates the risk of cross-site request forgery (CSRF) and information leakage attacks. The SameSite flag, which has not been fully adopted by all browsers, has been defined in a draft update to RFC 6265, which is the modern day standard for state management.

SameSite is a good example because since it is relatively new, many people may not have heard of it or know what it is used for. This is why it can be helpful to provide a little historical or informational context on the issue, in this case by stating that it was introduced by Google in 2016 and that has been defined in a draft update to RGC 6265. After reading this description, the client should have a much better understanding of the finding.

It also can be useful to provide a sentence or two in the description regarding what causes the finding and why it is in a concern. Although both of these topics will be addressed in more detail in the remediation and impact sections, a brief mention of these helps provide a good overview of the issue. In this way, the description is almost like a mini executive summary that allows the reader to quickly understand the finding as a whole.

Compare this to a quickly written finding on the same issue:

Description
The application sets a cookie without the SameSite flag.

If the reader is not familiar with SameSite, they may not fully grasp why they should address it. Obviously the reader can research the issue on their own, especially with the links you provide in the reference section. However, this is your chance to add real value to the vulnerability report by demonstrating your knowledge of the issue, educating your reader, and taking advantage of the attention that the reader is giving to your report.

A second part of the description is where you tailor the vulnerability for the environment where you tested. In the example above, the finding description is boilerplate that you can cut and paste for any client. The real benefit for your client is when you talk about how the finding applies in their current environment. Specifically, where did you find it and how did you exploit it? If the client is going to sufficiently remediate the issue, they need to have more details than just a generic description of the finding. It may be as simple as indicating the page and parameters that were vulnerable and the attack strings that triggered the issue. Even though you will be providing step-by-step instructions in the evidence section of how to reproduce the issue, this is where you catalog all the places where you found the issue and the ways you exploited it. This will make it much easier for the developer when they have to track down and address the issue in the code.

Here is an example:

The following cookies are lacking the SameSite flag:

[Insert cookie]

Impact

The impact describes what could happen if the client doesn’t remediate the issue. More specifically, it looks at the potential damage to the organization if the vulnerability were to be exploited. Damage could mean any number of things for an organization. It might be the loss or corruption of sensitive information, a disruption in operations, or harm to the organization’s reputation. The impact might be something qualitative such as impact to reputation or it could be quantitative such as a specific financial lost due to an interruption in business.

A number of factors can contribute to a finding’s impact. One major factor is the type of finding. Certain findings such as unrestricted file upload or SQL injection can cause much more damage to an organization when compared to other vulnerabilities such as a missing X-Content-Type-Options header. A second important factor in the level of impact is the sensitivity of the application and its data. A vulnerability in an application with publicly-available information has much less impact than an application with highly sensitive information such as medical records or intellectual property.

Sometimes a client will want you to use the impact level associated with previously issued findings. In other cases, you may have to make a determination of impact on your own. The point is to make sure you are consistent with impact so that findings issued over time for the same application have the same impact. If there is a reason to change the impact level, it should be documented in the finding. In the impact example below, a note is made about why the impact level is lower than what might be expected.

Impact
Without the SameSite flag, the application may be vulnerable to cross site request forgery (CSRF) and cross origin information leakage attacks since the browser will send cookies across origins. An attacker can use these attacks to trick a user into performing an action or into leaking sensitive data.

The impact of this issue is minimized because the application uses unique tokens to prevent CSRF attacks.

Risk

In addition to wanting to know the potential impact of a finding, clients will want to understand the risk associated with a finding. Although there are disparate views on risk within the field of information security, a popular approach is to understand risk as the impact of the finding associated with the likelihood of it being exploited. Risk helps the client ascertain how much they should care about the finding, how to prioritize it versus other findings, and whether they should invest in remediating it. Many approaches for calculating risk attempt to quantify it with CVSS being one popular framework. CVSS looks at a wide set of factors that could influence risk and allows you to calculate a score ranging from 0 to 10 with 10 being the most severe. Other approaches like OWASP (see table below) and NIST use a matrix of likelihood plotted against impact to determine a risk severity level.

Although the determination of likelihood may seem to be somewhat subjective, there are a number of factors that you can consider in order to make an appropriate judgement. According to NIST, three important variables are:

Attacker motivation and capability – are attackers motivated and able to pull off the attack?
Nature of the vulnerability – How difficult is it to exploit the vulnerability
Current controls – Are there mitigating controls that make an attack less likely?

One you have a risk determination based on likelihood and impact, you may need to negotiate over it with the client. What you consider as a high risk finding may seen as something less by your client because of compensating controls or some other factor in the environment that the client is aware of. The client may also have less virtuous reasons for wanting to reduce risk, such as an internal security policy or an auditing framework that require expensive mitigations for certain risk levels. However, if the client makes a valid argument for why impact or likelihood should be lower, you should be open to their feedback. I’ve seen testers become wedded to risk levels and attempt to fight the entire organization over an issue. In many cases the client knows the environment and their applications better than the tester and even if the risk is lowered, the client will still remediate it.

Risk

Likelihood – Low

Impact – Low

Overall Risk – Best Practice

Remediation

The remediation section of the finding provides a description of how a developer can fix the vulnerability. Even with the increased awareness today of security vulnerabilities, you should never assume that a developer knows how to properly fix a vulnerability. In some cases, there may different ways to address the issue, some being better than others. The more specificity you can provide and the more value you add to this section, the more likely the vulnerability is going to be successfully remediated.

Much like other parts of the finding, there is a generic, boilerplate component that talks about how to fix the issue and there is a more specific, tailored component that provides remediation advice for the specific environment. Obviously if the application is running on an Apache platform, then you don’t want to be providing .NET specific recommendations for how to update cookie flags in the web.config file.

In addition, the best remediation advice is one that takes a defense-in-depth approach. Your remediation recommendations should be thorough enough to cover a wide range of attack scenarios. For instance, with an unrestricted file upload vulnerability, it is not enough to ask the developer to restrict file extensions on uploaded files. There are many other defensive measure they should take including verifying that the file has the appropriate content, using randomly generated names, implementing virus scanning, and not placing the file in a directory accessible by users, just to name a few.

Remediation
Configure the application to set the SameSite flag. As this is a relatively new cookie attribute, the flag may need to be set programatically by code on the server side. Set the attribute as such:

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

The SameSite attribute can be set with two values:

Strict – The cookie is not sent with any cross-site requests, even if the user follows a link to a third party site.
Lax – The cookie is sent with a top-level GET request, such as a user following a link to a third party site.

Since the SameSite flag is not implemented by all browsers, use a defense-in-depth approach and deploy the standard prevention for CSRF and information leakage attacks. In addition, the SameSite flag won’t prevent CSRF that occurs within a single origin or through an XSS attack.

Evidence

In the evidence section, you document the finding and how you discovered it. You should provide a clear step-by-step description with screenshots of how to exploit the vulnerability. This is especially helpful for developers when they attempt to remediate the finding. With this information, they can test and confirm the issue themselves after a fix ensuring that when the finding comes back to you for a retest, it will most likely have been successfully remediated. There is nothing more frustrating then having to retest a finding several times because the developer got the remediation wrong.

 

 

Documenting the finding with screenshots also covers you in the event that the client challenges your finding. There may be times when a client cannot imagine that their application would be vulnerable to a particular finding. If you have a clearly documented vulnerability, anyone who reads the report should be convinced of its validity. In addition, if something changes after you found the issue, screenshots capture the point in time when the application was vulnerable.

Evidence

  1. Configure a browser to use a proxy such as Burp Suite.
  2. Log into the application at the following url: https://www.example.com.
  3. Capture the response in Burp Proxy.
  4. The Navigator_JSESSIONID cookie is set without the SameSite flag.

References

Even though your finding should be thorough enough that the organization understands the issue, the risk, and the remediation, you should provide references so that developers and others can look up additional information on the issue as needed. In many cases, these will be standard OWASP and CWE type references. In other cases, the references may include specific articles from vendors or expert sources that provide specialized advice on an issue. Even with the power of Google, don’t assume that your client will be able to find appropriate sources for the finding. Sometimes, articles written on vulnerabilities may be incomplete or wrong, so not providing the appropriate resources could cause the client to improperly implement a remediation. Take the time and provide high quality references for the client and they will appreciate your effort.

References

OWASP – https://www.owasp.org/index.php/SameSite

Draft RFC – http://httpwg.org/http-extensions/draft-ietf-httpbis-cookie-same-site.html

Caniuse – https://caniuse.com/#search=samesite
Although writing an application security finding is not an exact science, if you take take your time, do the research, include the most important sections as described above, and tailor the information for the client, your findings will allow your clients to understand the issues, the risk to the organization, and how to prioritize appropriate remediations. You will also be adding significant value to the reporting process which many (unfortunately not all) clients will acknowledge and appreciate.

Good luck and happy finding writing!

 

Here is the complete SameSite Not Set finding:

Description
The application uses a cookie that is set without the SameSite flag. The SameSite flag is a browser-based standard introduced by Google in 2016 that instructs browsers to prevent cookies from being sent in cross-site requests. Restricting cookies to their initial origin mitigates the risk of cross-site request forgery (CSRF) and information leakage attacks. The SameSite flag, which has not been fully adopted by all browsers, has been defined in a draft update to RFC 6265, which is the modern day standard for state management.

The following cookies are lacking the SameSite flag:

[Insert cookie]

Impact
Without the SameSite flag, the application may be vulnerable to cross site request forgery (CSRF) and cross origin information leakage attacks since the browser will send cookies across origins. An attacker can use these attacks to trick a user into performing an action or into leaking sensitive data.

The impact of this issue is minimized because the application uses unique tokens to prevent CSRF attacks.

Risk

Likelihood – Low

Impact – Low

Overall Risk – Best Practice

Remediation
Configure the application to set the SameSite flag. As this is a relatively new cookie attribute, the flag may need to be set programatically by code on the server side. Set the attribute as such:

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

The SameSite attribute can be set with two values:

Strict – The cookie is not sent with any cross-site requests, even if the user follows a link to a third party site.
Lax – The cookie is sent with a top-level GET request, such as a user following a link to a third party site.

Since the SameSite flag is not implemented by all browsers, use a defense-in-depth approach and deploy the standard prevention for CSRF and information leakage attacks. In addition, the SameSite flag won’t prevent CSRF that occurs within a single origin or through an XSS attack.

Evidence

  1. Configure a browser to use a proxy such as Burp Suite.
  2. Log into the application at the following url: https://www.example.com
  3. Capture the response in Burp Proxy
  4. The Navigator_JSESSIONID cookie is set without the SameSite flag

References

OWASP – https://www.owasp.org/index.php/SameSite

Draft RFC – http://httpwg.org/http-extensions/draft-ietf-httpbis-cookie-same-site.html

Caniuse – https://caniuse.com/#search=samesite