RISK DEEP DIVE Prioritizing Vulnerabilities Let’s say you get an application pen
ID: 3670990 • Letter: R
Question
RISK DEEP DIVE
Prioritizing Vulnerabilities
Let’s say you get an application penetration testing report back for your internal intranet site, and there are two findings as follows:
1. Cross-site scripting vulnerability
2. Privilege escalation vulnerability
Both were rated as high risks by the testing team, but there are only enough development resources to fix one in the next release of the intranet application. How would you advise senior management?
If you aren’t familiar with the details of these vulnerabilities, start with a quick Google search. Cross-site scripting on a public-facing application might be a big risk, but for an internal application, it just isn’t as exploitable. The privilege escalation has a much higher likelihood of being abused because it would be a more attractive attack vector for malicious insiders.
Keep in mind that risk can never be eliminated unless the threat is completely removed, the weakness is totally fixed, or the scenario is avoided altogether. As opposed to remediation actions that would fix a vulnerability, most mitigation actions are simply going to decrease the risk. For example, putting in a firewall is a mitigation step that doesn’t eliminate the risk of a network compromise, but it does reduce the likelihood of this occurrence. Automatically purging sensitive data from a server after 90 days may reduce the severity of a compromise because less data is exposed. The goal is to reduce risk to an acceptable level without hindering business processes. If you get caught up in trying to eliminate (or remediate) every risk, you may be wasting resources. A certain level of risk exposure is almost always acceptable.
Q1: Discuss and identify, how the risk was reduced to the acceptable level in the organization?
Explanation / Answer
Correction must be done in the application directly. You should always parse user's input
before inserting it directly to be rendered into client-side browser. Developers must realize the
only way to a secure application is always sanitize user's input.
Reliable avoidance of cross-site scripting vulnerabilities currently requires the encoding of all
HTML special characters in potentially malicious data. This is generally done right before
display by web applications (or client-side script), and many programming languages have builtin
functions or libraries which provide this encoding (in this context, also called quoting or
escaping).
The best way to protect a web application from XSS attacks is ensure that your application
performs validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all
parameters) against a rigorous specification of what should be allowed. The validation should
not attempt to identify active content and remove, filter, or sanitize it. There are too many types
of active content and too many ways of encoding it to get around filters for such content. We
strongly recommend a ‘positive’ security policy that specifies what is allowed. 'Negative' or
attack signature based policies are difficult to maintain and are likely to be incomplete.
Correction must be done in the application directly. You should always parse user's input
before inserting it directly to be rendered into client-side browser. Developers must realize the
only way to a secure application is always sanitize user's input.
To reason about a web application’s authorization correctness,
one must examine each sensitive operation (e.g. each SQL queryexecution) of the program and examine the authorization information
required to perform that operation.
identifies what can go wrong in the implementationof access control, including the absence of any authorization
checks, improper ownership or privileges corresponding touser role, and untrusted session variables.
Authorization state Applications should ideally have a welldefinedpolicy manifest of what authorizations should be granted
to what users, taking into account the session context, but unfortunatelythis is not always explicit. Even in applications that manage
to have policy documents, the implementation may not match thespecification. The best understanding of access policy therefore
is the operating context of each access request in the implementation
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.