XSSCross-site scripting

What is Cross-site Scripting (XSS)

Cross-site scripting is often referred to or abbreviated as XSS because it occurs on the client side. Here the attacker aims to inject some malicious scripts into the user’s web browser, by sending a link to the user and provoking the user to click it. If any action is performed by the user on those links, then the actual attack occurs, resulting in stealing the user’s active session cookies, sensitive data, session hijacking, and much more. But it can only occur when the web application or app is vulnerable to XSS attacks which means if the website or app lacks/misses some proper data sanitation then the codes present on those links can harm the client-side web browser. 

The attackers do not have specific targets. In many cases, they do go for a direct way which is via email messages. XSS attacks can be done by using different programming environments including VBScript, Flash, ActiveX, JavaScript, and even CSS. However, JavaScript is mainly used for these types of attacks because JavaScript is fundamental to many websites.

 

Cross-site scripting XSS attack

How does Cross-site Scripting Works?

Let us imagine, a user is sitting on his computer and visiting a web page that is filled with interesting headlines, funny videos, ads for sporting goods, online stores, and a payment site. With a simple click on any advertising, the banner triggers another page. Now here comes the two stages of a typical XSS attack:

  • The attacker first finds a way to inject the malicious JavaScript code into the user’s web page that the user is visiting.
  • Now since the user is visiting the web page containing the malicious JavaScript code, the attacker then uses social engineering and/or phishing to send malicious URLs to the user which is connected to the attacker’s account. 

These attacks can also trigger automatically, while the page loads or when a user visits some specific elements of the page. There are also some consequences of cross-site scripting attacks, which include:

  • Capturing the keystrokes of a user.
  • Redirecting the user to a malicious website.
  • Running a web browser that is crashing the browser.
  • Obtaining the cookie information of a user.

There are also some cases where the attack leads to a complete compromise of the user’s account.

Real-Time Splunk SIEM Training by SIEM XPERT

Registration is open for upcoming Batches…

Types of XSS/Cross-Site Scripting Attacks

Since we have discussed working on cross-site scripting, now let us know about the types of cross-site scripting attacks:

There are 4 types of cross-scripting/XSS attacks:

  • Stored XSS attacks – It is also known as Persistent Cross-site Scripting. In these attacks, the injected JavaScript codes are permanently stored on the user’s server like in the databases, in a message forum, in visitor log, etc. The most frequent targets are those websites that allow the users to share content, including blogs, social networks, video sharing platforms, and message boards. The number of times the infected page is viewed, the malicious script code is transmitted to the user’s browser. For example, a marketing approach displaying social media posts, or a network monitoring approach displaying packet data from network traffic.
  • Reflected XSS attacks – It is also known as Non-Persistent Cross-site Scripting. In this type of attack, the injected JavaScript code is reflected off the web server in the form of error messages, search results, or any other responses that include some part of the request. The delivery of this attack can be via another route like e-mail messages or some other websites. An example of Reflected cross-site scripting can be a search form, where users upload their search query to the server, where only they can see the results. Then the attackers send the user’s custom links that redirect toward a vulnerable page. Hence, from this page, they often employ a variety of methods to trigger their proof of concept.
  • Blind XSS attacks – It is the form of persistent XSS which occurs when attackers are not sure about the result of the attack because the vulnerability lies on the page which can only be accessed by an authorized user. Since the attackers do not get notified, they often use polyglots which are designed to work in different scenarios. Let’s take an example of feedback forms, where the attacker submits a malicious payload using the form, and when the backend admin of the application opens the attacker’s submitted form via the backend application, the attacker’s payload then gets executed.
  • DOM-Based XSS attacks – The full form of DOM is Document Object Model. Here the attackers can read and manipulate the DOM data and can craft a malicious URL. The attackers provoke the users to click on the URL so that they can steal users’ active session information, keystrokes, and so on. The DOM-Based XSS attack occurs entirely on the client’s browser.

How to avoid XSS vulnerabilities?

There are a few strategies that can help to avoid XSS vulnerabilities and these include:

  • Do not trust user input.
  • Execute output encoding.
  • Perform user input validation.
  • Do follow the Defence in Depth principle.
  • While developing a web application, ensure to align it with OWASP’s XSS Prevention Cheat Sheet.
  • Also, perform penetration testing to confirm the result.

The organization can also be protected by following secure development guidelines. Output encoding is the key to avoiding XSS vulnerabilities.

Cross-site scripting (XSS) examples

The main goal of an XSS attack is to access the user’s information. Let’s look at some examples of these attacks:

  • Session Hijacking – It is considered the most dangerous and widespread method of web session hijacking. So, it is mainly done to exploit the web session control mechanism, which is managed for a session token. The attacker can cause harm to the session token by using malicious JavaScript code running on the client side. If the attacker sends the malicious link to the user and the user clicks on the link, then the code will run and the attacker can obtain full access to the session key. Hence, it is very important to set the server in the HttpOnly attribute in session cookies. 
  • Phishing attacks – The attack without an XSS component happens when the attackers try to make the fake link as real as possible to the user or victim. These links are generally the textual form of a trusted URL with a hyperlink to another website or a brand’s website. The fake links are inserted with the number to make the link appear real. In the attack, with the XSS component, query strings are injected into the malicious URLs and are sent to the victims which makes the fake URLs harder to spot. Phishing attacks done using query strings are very effective because the URLs of actual websites are used rather than fake links.

 

Read about What is Log4j vulnerability and how to detect and fix it? 

 

What are the consequences of XSS attacks?

The consequences that may occur due to these attacks are:

  • The attackers can read any data and perform arbitrary actions which may include postings on social media or bank transactions.
  • Stop user’s input.
  • Ruin web pages.
  • They can inject malicious codes into web pages.

Uses of Cross-Site Scripting

The attacker who exploits the cross-site scripting vulnerability is able to:

  • Impersonate as the victim user.
  • Carry out any action that the user is able to perform.
  • Read the data that the user is accessing.
  • Capture the user’s credentials.
  • Inject Trojan functionality into the website.

Cross-site scripting/XSS attack prevention 

  • Maintain Awareness – While developing a web application the development team is developers, QA staff, DevOps, and SysAdmins should be aware of the risks associated with the XSS vulnerabilities.
  • Distrust User Input – The user input used as a part of HTML output may have a risk of XSS. So, the user should treat every input as untrusted.
  • Sanitize HTML – As the user input should contain HTML, it can’t be escaped/encoded as it might break some valid tags. So, in such cases, the user can use a trusted library to parse HTML. 
  • Set HttpOnly flag – The HttpOnly flag is set for cookies because it is not accessible via client-side JavaScript.

 

Must read our previous blog on SOC Analyst interview questions that are frequently asked…….

We do offer our trainings at your city also :

ArcSight Training in Kolkata , ArcSight Training in Mumbai , ArcSight Training in Noida , ArcSight Training in Trivadrum , ArcSight Training in Visakhapatnam , ArcSight Training in Pune 

32 Comments

  1. Oh my goodness! Incredible article dude! Thank you so much,
    However I am going through issues with your RSS. I don’t understand the reason why I am unable to subscribe to it.
    Is there anybody getting the same RSS issues? Anyone that knows
    the answer will you kindly respond? Thanx!!

  2. Heya i am for the primary time here. I found this board and I find It
    truly useful & it helped me out much. I’m hoping to offer one thing back and aid others such as you aided
    me.

  3. Pingback: URL
  4. Pingback: D Health Plus
  5. Pingback: ks lumina pod
  6. Greetings from Florida! I’m bored to death at work so
    I decided to check out your site on my iphone during lunch break.
    I enjoy the info you provide here and can’t wait to take a look when I get home.
    I’m amazed at how fast your blog loaded on my phone .. I’m not even using
    WIFI, just 3G .. Anyways, awesome blog!

  7. Pingback: ruger firearms
  8. Can I just say what a comfort to discover someone that genuinely
    understands what they’re discussing over the internet.
    You certainly realize how to bring a problem to light
    and make it important. More and more people have to look at this and understand this side of your story.
    I was surprised that you are not more popular since you definitely
    possess the gift.

    Here is my blog post; vpn special coupon code 2024

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment