Cross-Site Scripting (also known as XSS) is one of the most common application-layer web attacks. XSS vulnerabilities target scripts embedded in a page which are executed on the client-side (in the user’s web browser) rather than on the server-side. XSS in itself is a threat which is brought about by the internet security weaknesses of client-side scripting languages such as HTML and JavaScript. The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner desired by the malicious user. Such a manipulation can embed a script in a page which can be executed every time the page is loaded, or whenever an associated event is performed.
XSS is the most common security vulnerability in software today. This should not be the case as XSS is easy to find and easy to fix. XSS vulnerabilities can have consequences such as tampering and sensitive data theft.
Key Concepts of a Cross-Site Scripting Attack- XSS is a Web-based attack performed on vulnerable Web applications
- In XSS attacks, the victim is the user and not the application
- In XSS attacks, malicious content is delivered to users using JavaScript
Explaining Cross-Site ScriptingAn XSS vulnerability arises when Web applications take data from users and dynamically include it in Web pages without first properly validating the data. XSS vulnerabilities allow an attacker to execute arbitrary commands and display arbitrary content in a victim user's browser. A successful XSS attack leads to an attacker controlling the victim’s browser or account on the vulnerable Web application. Although XSS is enabled by vulnerable pages in a Web application, the victims of an XSS attack are the application's users, not the application itself. The potency of an XSS vulnerability lies in the fact that the malicious code executes in the context of the victim's session, allowing the attacker to bypass normal security restrictions.
XSS Attack Examples- Reflective XSS - There are many ways in which an attacker can entice a victim into initiating a reflective XSS request. For example, the attacker could send the victim a misleading email with a link containing malicious JavaScript. If the victim clicks on the link, the HTTP request is initiated from the victim's browser and sent to the vulnerable Web application. The malicious JavaScript is then reflected back to the victim's browser, where it is executed in the context of the victim user's session.
- Persistent XSS - Consider a Web application that allows users to enter a user name which is displayed on each user’s profile page. The application stores each user name in a local database. A malicious user notices that the Web application fails to sanitize the user name field and inputs malicious JavaScript code as part of their user name. When other users view the attacker’s profile page, the malicious code automatically executes in the context of their session.
Identifying Cross-Site Scripting VulnerabilitiesXSS vulnerabilities may occur if:
- Input coming into Web applications is not validated
- Output to the browser is not HTML encoded
Impact of Cross-Site ScriptingWhen attackers succeed in exploiting XSS vulnerabilities, they can gain access to account credentials. They can also spread Web worms or access the user’s computer and view the user’s browser history or control the browser remotely. After gaining control to the victim’s system, attackers can also analyze and use other intranet applications.
By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:
- Hijack an account
- Spread Web worms
- Access browser history and clipboard contents
- Control the browser remotely
- Scan and exploit intranet appliances and applications
Preventing Cross Site Scripting (XSS) VulnerabilitiesXSS can only be prevented by carefully sanitizing all input which is not known to be secure. Classes of input which is known NOT to be secure include:
- HTTP referrer objects
- The URL
- GET parameters
- POST parameters
- Window.location
- Document.referrer
- document.location
- document.URLUnencoded
- All headers
- Cookie data
- Potentially data from your own database (if not properly validated on input)
Preventing XSS is an arduous job - all the values found via the above method must be checked for XSS attack vectors, which come in many forms. For instance, the same XSS code may come in a dozen different forms, based on how it is encoded and special characters placed inside.
If it is possible to whitelist data being input, then create a careful filter to whitelist the input.
Alternately, if the data is never output to a user's browser, then it cannot be used in an XSS attack. Be careful relying on this method, as other attacks, such as HTTP Response Header Splitting or SQL Injection attacks use similar untrusted data sources to perform other types of attacks.
The best defense is to escape all user input. The level of escaping and how it should be implemented will be dependent on the specific site requirements. For instance, some sites wish to allow users to add some HTML tags, while others have no need of such functionality, and can more aggressively scan.
.jpg)
Posts
![SQL Injection Basics - Union Based [Detailed Tutorial]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjQpa2wuMB-m5CXPVf71GUOkfiIOQA8KTyQ-_zfAl0SZa23UBN1QJaO2ZMGRDZlmDJTYf2jJ4ik3Xnj1locc38Yv9l6VMxTWt32s86JtXtLABDn20DRuAcbLPKMb9m2hc6PDmjIjvU-us/s72-c/SQL-Injection-Attack.jpg)
