Cross-Site Scripting (XSS) attacks are a kind of injection, in which harmful/malicious scripts are injected into benign and trusted websites. XSS attacks happen when an attacker uses a web application to send harmful/malicious code, generally in the form of a browser side script, to a different end-user. We as Freelance Web Developer Singapore have given detailed information about XSS. Let’s find out more…
An attacker can use XSS to push a harmful script to an unsuspecting user. The end user’s browser has no way to get to know that the script is not trusted anymore, and execute the script in the browser. Because the as per browser thinks the script came from a trusted source, the harmful/malicious script can access any session tokens cookies, or any sensitive information retained in browser and used with that website. These scripts can even be used to rewrite the content of the HTML page.
The figure below explains a step-by-step go through a simple XSS attack.
When XSS occurs?
The Cross-Site Scripting (XSS) attacks happen when:
1. Data enters into a web application from an untrusted source, mostly from a web request.
2. The data included in dynamic contents that are sent to a web user without putting any kind of validation for unknown/malicious content.
The unknown harmful/malicious content pushed to the web browser often uses the form of a section of JavaScript code, but it may also include HTML, Flash, or any other kinds of code that the web-page may execute. The variety of attacks based on XSS have no limit, but they commonly include transmitting private/personal data, like cookies or other session information, to the attacker, redirecting the victim to a web-page which is controlled by the attacker, or performing other unusual harmful operations on the user’s system.
What are types of XSS?
Early, only two primary types of XSS were identified, Stored XSS, and Reflected XSS. And In 2005, Amit Klein introduced a third kind of XSS, which Amit added a DOM Based XSS. The 3 types of XSS are defined as follows:
1. Stored XSS (AKA Persistent or Type I):
The Stored XSS generally happens when the user input is stored on the target web server, like in a database, in a message of a forum, in the visitor logs, in the comment field, etc. And then an attacker is able to fetch the stored data from the web application without that data being made safe to render in the web-browser. With the arrival of HTML5 and other browser technologies, we can visualize the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the server at all.
2. Reflected XSS (AKA Non-Persistent or Type II)
Reflected XSS happens when user’s input immediately gets back by a web application in an error/warning message, the result of a search, or any other kind of response that includes few or all of the input provided by a user as a portion of the request, without being safe the data, to render in the browser, and without permanently storing the user-provided data.
3. DOM Based XSS (AKA Type-0)
Basically DOM Based XSS is a form of XSS where flow of polluted data from source to sink takes place in the browser, i.e., the source of the data is in the Document Object Model (DOM), the sink is also in the DOM, and the data flow never leaves the browser i.e. both source and sink are in the DOM only and does not get stored on the server. For example, the source (where malicious data is read) could be the URL of the page (e.g., .href), or it could be an element of the HTML, and the sink is a very sensitive method call that causes the execution of the harmful/malicious data (e.g., ).”
For years, most people know only these (Stored, Reflected, DOM) as three different types of XSS, but in reality, there is something else, they overlap. You may have both Stored and Reflected DOM Based XSS. One can have Stored and Reflected Non-DOM Based XSS also, but its bit confusing, so to help explain the things, starting about mid-2012, the research community suggested and started using two new names to help organize the types of XSS that can occur:
● Server XSS
● Client XSS
Server XSS:
Server XSS occurs if there is an untrusted user-supplied data which is included in a server generated HTTP response. The data source could be from a stored location or from a request. As such, you may have both Reflected Server XSS and Stored Server XSS.
In the case above scenario, all the vulnerability(s) is/are in server-side code or script, and the browser is only rendering the response and executing any valid script embedded in it and displaying on the web-page.
Client XSS:
Client XSS occurs when untrusted user-sent data is used to update the DOM of the web-page with an unsafe JavaScript call. A JavaScript call becomes unsafe if it can be used to introduce valid JavaScript into the DOM. The source of this data could be from the DOM, or it could have been sent by the web-server (using an AJAX call, or a page load). The source of the data could have been from a request, or from a stored location on the client or on the server. As such, you may have both Reflected Client XSS and Stored Client XSS. For details on Mobile App Developer Singapore feel free to connect.
Note: With these new definitions, the definition of DOM Based XSS doesn’t change. DOM Based XSS is a subset of Client XSS.
What are the consequences of XSS Attack?
A few consequences of XSS attack is mentioned below:
❏ Stealing user accounts details, such as the system login account, the user online banking details, and other various administrator accounts.
❏ Control over enterprise or professional data, including the ability to read, tamper with, add, and delete sensitive corporate data.
❏ Theft of important business-worthy information
❏ Illegal transfer
❏ forced to send email
❏ the website hangs horse
❏ Control the victim system to perform various attacks on other websites.