For certifications such as CISSP, CISA, Security+, CASP+, or CySA+, web vulnerability classes make up only a small part of the knowledge required to pass the exam. For instance, the CISSP exam evaluates the student’s expertise in eight domains, and even advanced knowledge of subjects like XSS, CSRF, and SQL injection would cover merely parts of what in itself is at most a subset of only one of those domains (Domain 8: Software Development Security). Rest assured that we are only using CISSP and the associated Common Body of Knowledge (CBK) as an example – the technical aspects of web security play a similarly small role in the official CBKs and exam outlines of other popular certifications, such as (ISC)2 CISSP-ISSAP, SSCP, and CSSLP, and, to cross the chasm to other certification bodies, ISACA CISA, CompTIA Security+, CASP+, and CySA+.
Why is it then that many students choose to invest considerably more time and effort into gaining a sound understanding of web vulnerability classes than what can be justified by their weight within the syllabus alone? One plausible explanation is today’s prevalence of web technologies, combined with our inherent desire to understand what we use on a daily basis. From an exam taker’s perspective, the reason might be even more straightforward: nobody wants to walk into an exam with what they know is a blind spot, and a testable one at that, no matter how small and irrelevant it may seem. This has become a particularly important factor with the emergence of CAT exams, which are specifically designed to – rather mercilessly – expose even the smallest gaps in the examinee’s knowledge by dynamically selecting questions based on the correctness of previously answered ones.
At the same time, self-study of even common web vulnerability classes like XSS, directory traversal, and SSRF can be quite daunting for students who lack hands-on technical experience, let alone those who lack the inclination to obtain such experience. This holds particularly true for students who seek to obtain a certification with a focus on (risk) management, auditing, IAM, or compliance, and who wish to understand the basics of web security without having to scour through articles and literature written with a more tech-savvy audience in mind.
It does therefore not come as a surprise that study groups and forums are frequently used to ask questions about the different types of cross-site scripting, cross-site request forgery, and SQL injection. It is as unfortunate as it is to be expected that popular study materials, certification guides, and preparatory courses tend to be rather light on the technical side of things and do not always manage to convey correct, let alone understandable explanations.
At Invicti, we possess vast experience not only with the automated discovery of web vulnerabilities but also with communicating them to stakeholders of various levels of technical expertise. For example, Acunetix scan results can be exported as report types with different levels of detail, with each report type carefully designed to meet the needs of either a particular audience or a set of compliance requirements.
This article aims to explain typical web vulnerability classes and defenses at a high level, in simple terms, and in a succinct manner. We will be focusing less on technical minutiae, and more on ensuring that you gain the solid foundational knowledge that will not only allow you to approach your certification exam with confidence but to understand the subject at a level that will prove useful during your entire career. For readers wishing to learn more about the web vulnerabilities discussed below, we provide links to more in-depth articles.
XSS (cross-site scripting)
Description:
An attacker submits carefully crafted input to a server, which then uses this input to generate a web page that is delivered to the victim’s web browser.
Impact:
The attacker’s script code becomes part of the web page and runs inside the victim’s web browser within the context of the vulnerable web page.
Prevention:
While generating a web page containing user input, web servers should encode user input to ensure it is merely displayed, but never interpreted by the web browser. As a compensating control, web servers may provide web browsers with a Content Security Policy to limit the impact of failure to properly encode user input.
Further reading:
CSRF (cross-site request forgery); sometimes abbreviated as XSRF
Description:
An attacker tricks a victim’s web browser into sending an unintended request to a server, either by sending the victim a link pointing to the vulnerable web server or by crafting a web page that initiates the request.
Impact:
The server treats the attacker-initiated request as if it were a request initiated by the victim, and performs actions in the context of the victim’s authentication.
Prevention:
Web servers should instruct the web browser to mark genuine requests with a token the attacker cannot guess. If authentication is managed through the use of cookies, the cookies should use the SameSite attribute to prevent them from being used in attacker-initiated requests.
Further reading:
SQL injection
Description:
A server passes the user input to a database, and an attacker manages to craft such input in a way that causes it to be treated not as data, but as a database command.
Impact:
The attacker can instruct the database to perform actions and may be able to use this ability to read, write, modify, and delete data stored in the database.
Prevention:
When web applications pass user input to a database, they should maintain a clear distinction between user data that is written to, or used to query, the database, and commands that are designed to manipulate the database. This can be achieved through the use of prepared statements, parameterized queries, and stored procedures.
Further reading:
Directory traversal/path traversal
Description:
A web application accesses a resource on a filesystem, and the location of the accessed resource is derived from user input. An attacker submits input that causes the web application to access a resource that is not meant to be accessed.
Impact:
The attacker may be able to read, write, or otherwise manipulate arbitrary resources, effectively abusing the permissions of the web application.
Prevention:
Web applications should avoid the direct use of user input to construct resource paths or references. If that is not possible, access controls, such as restrictive file and directory permissions, must be in place to limit access to predefined resources.
Further reading:
SSRF (server-side request forgery)
Description:
A web server is capable of sending outgoing requests, and an attacker causes the server to send either arbitrary requests, or to send any type of request to unintended destinations.
Impact:
The attacker may abuse the trust relationship between the vulnerable server and the recipient of the forged requests, or exfiltrate sensitive information by forcing the vulnerable server to send requests to a server controlled by the attacker.
Prevention:
Servers should either not allow users to initiate requests to arbitrary destinations, or ensure that users’ control over request contents and request destinations does not exceed requirements set out by the application’s business logic requirements.
Further reading:
XSS prevention and mitigation
A surprising number of study materials recommend input validation as the best protection against XSS. There are multiple problems with this approach, and all of them are known to have caused countless real-world security issues. For example, just because the input is deemed valid in the context of the application’s business logic does not mean it is safe enough, let alone secure enough, to be processed in another context.
In addition, reliance on input validation assumes that developers are aware of all sources through which data can enter the system, both at the time the input validation is designed and at any future time. Similarly, in order for input validation to be a sufficient means of preventing cross-site scripting, all contexts in which user input is ever used as output would have to be known in advance.
That brings us to the single most important reason why input validation alone is not effective in preventing XSS vulnerabilities: the vulnerability is ultimately exploited in the client’s web browser – after the malicious, attacker-supplied data has been used to generate a response, such as a web page. It then follows that it is only at this stage that XSS can be effectively prevented, and by encoding or escaping data in the context in which the output is about to be used. For example, inserting user-provided text inside an HTML web page requires an entirely different approach to output encoding than inserting the exact same text inside an XML file, a JSON response, a CSV file, or JavaScript code.
The difference between XSS and CSRF
A common question in certification-related study groups is how to best explain the difference between cross-site scripting and cross-site request forgery.
The confusion surrounding these two terms does not come entirely unexpected, and for three reasons:
- In many of the study materials on the market today, XSS and CSRF are usually among the first web vulnerability classes to be explained.
- Both XSS and CSRF target the trust relationship between the web browser and the web server.
- Considering that both begin with “cross-site”, a student may be forgiven for being misled into believing that the two vulnerability classes must be directly related.
Fortunately, similar naming does not translate into equally similar characteristics, and the above explanations should have made it quite clear that we are looking at two entirely different vulnerability classes.
To clarify further, one way of understanding the differences between two things is to strip them of what they have in common and to focus on what remains. In the case of cross-site scripting and cross-site request forgery, removing “cross-site” leaves us with:
- “Scripting”, which refers to a web browser executing (potentially malicious) scripts, and
- “Request forgery”, which means that a web browser sends requests forged by an attacker.
It is worth mentioning that a number of study materials, including practice tests, seek to classify XSS as an attack against the client, and CSRF as an attack against the server. Although not wrong per se, this distinction can be misleading, both in terms of how these vulnerabilities are usually exploited, and how they should be mitigated. For example, in the case of XSS, it is still necessary to make server-side changes to truly remediate the vulnerability. Client-side XSS protection, such as those present in Internet Explorer and earlier versions of Google Chrome, has been found to be insufficient and to occasionally cause additional security issues. Similarly, CSRF may well be viewed as an attack against the server, but it is usually the authentication of the client-side victim that defines the impact of the vulnerability and the severity of the resulting risks.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Senior Security Researcher
