What is Stored Cross Site Scripting or Stored XSS ?

What is Stored Cross Site Scripting or Stored XSS ?

As we know that there are two types of Cross Site Scripting namely Reflected Cross Site Scripting (Reflected XSS) and Stored Cross Site Scripting (Stored XSS). In our previous articles we have learned about Reflected XSS and how does it works. Today we will learn about most dangerous type of Cross Site Scripting attack i.e. Stored Cross Site Scripting. Web applications which allow users to store data are usually exposed to Stored Cross Site Scripting.

Stored Cross Site Scripting or Stored XSS usually occurs when a web application (say website) takes input from a user via some web forms (usually input forms for example, shopping cart, Forum, contact page, user or profile pages, blogs, settings page etc i.e. from where application accepts data and store it into database) and user injects malicious code into it, and the field in which user has entered the malicious code is not validated correctly and data is stored in some database for future use. As a result, the malicious data inserted by hacker appears to be part of the website or web application and runs in victim’s web browser (as per privileges set for web application) and it can result into complete hold over victim’s machine based on the arbitrary code inserted by the hacker. Likes we studied in Reflected XSS, an XSS attack allows hackers to install browser based Keyloggers, steal session cookies or sensitive information or change data on the web page usually download links etc.

In case of Stored XSS, there is not need of exploiting a malicious link. An exploit automatically triggers when any user visits the web page containing stored XSS. We can define a typical Stored XSS attack in below steps:

1. Hacker identifies the vulnerable website which asks for data from user and stores it into website database.
2. Attacker injects the arbitrary code into the vulnerable page.
3. User visits the vulnerable page on website which contains the Stored XSS.
4. Arbitrary or malicious code is executed by the user’s web browser.

This is how stored XSS attack works. Now below are after effects that a hacker can achieve after successful XSS attack:

1. Hijacking User’s Web browser
2. Install JavaScript or vbscript browser based Keyloggers to capture key strokes of victim.
3. Capture sensitive information of the users visiting the vulnerable website like session cookies etc.
4. Can deface website
5. Redirect users to other malicious websites.
6. Changed download links and expose users to download other malicious software’s like Rat’s, Trojans, Keyloggers etc.

Stored Cross Site Scripting attack can be exploited using various browser based exploitation frameworks available online like XSS Proxy, Backframe, BeEF etc.

That’s all for today! We will learn Stored XSS in detail with help of practical examples in later tutorials, so keep connected.

How to Find Reflected Cross Site Scripting Vulnerability

In our previous tutorial, we have learned about Reflected Cross Site Scripting and 3 basic steps to identify and detect Reflected Cross Site scripting in any website or web application. Let’s have a quick view of previous tutorial; Reflected Cross site scripting or Reflected XSS occurs when hacker injects browser executable JavaScript or VBScript (or some code snippet) in the web request parameters like URI or HTTP Parameters. Reflected XSS attack is done in two steps, first finding the vulnerable web request parameters like URI or HTTP parameters and second social engineering i.e. convincing victims to click the malicious link. Hackers use Reflected XSS vulnerability to install Keyloggers, steal session cookies or simply changing content of the page and much more.

But why it’s called Reflected? It’s called Reflected XSS because it involves crafting a request containing embedded JavaScript which is reflected back to any user who makes the request.

Note: This tutorial is just for educational purposes.

Very common example of Reflected XSS that most of you might have noticed is that. Your twitter account or Facebook account or some other account is posting something which you haven’t submitted and theses mysterious posts are promoting some “xyz.com” website or some spam messages or some game.

But how Reflected XSS actually happens?

Step1: Finding the Vulnerable URL and Crafting URL

Suppose we have an ecommerce portal say abcdef.com which has multiple URI or HTTP parameters and one of its parameters say “item” is not validated correctly and “item” parameter is vulnerable to XSS. Now what hacker will do is that he will attach his malicious JavaScript hosted on some xyz.com website in that vulnerable URI or HTTP parameter and craft a URI. Say below is potential vulnerable URL:

www.abcdef.com/products.php?item=1

Now hacker will inject his/her malicious script in “item” parameter and vulnerable link will become something like below:

www.abcdef.com/products.php?item=”><script>EvilFunction()..</script>

Step 2: Social Engineering Workaround

 Now attacker will send this Crafted URL to victim via some social engineering technique like email or chat or some offer and trap victim to click the link. Some of social engineering tricks that hacker uses are mentioned below:

• SPAM emails containing a crafted link or HTML code
• Malicious web pages containing a malicious URL
• Click Jacking
• Social media: messages / posts containing a malicious link
• XSS techniques: using Persistent (Stored) XSS, malicious links can be saved as part of forum posts / comments and reflected back to visiting users
• Other types of attacks: DNS rebinding – compromises the hosts file causing your browser to get redirected to malicious pages instead of the intended web page, compromising the wireless router, etc.

Once the victim has clicked on the malicious link, and if the attack is successful, the payload will get executed in the victim’s context and call home to the attacker in order to communicate the results, as well as upload stolen data, etc. The consequences vary, because the attack enables execution of arbitrary code, usually with elevated privileges – as most users still use the default “administrator” account and although latest Windows operating systems come with user access control and hardened browser policies, they are usually disabled in order to improve on the user security.

Wow now what? Nothing it’s up to the attacker script i.e. for what functionality it is written, normally it contains browser based Keyloggers and session cookie stealers coded in JavaScript or VBScript and you can understand what a Keylogger can do or what will happen is somebody steals your session cookie. Now imagine if abcdef.com website is some bank website or social networking website. Results can be catastrophic.

That’s all guys! Hope this tutorial helps you.

Browser Cookies Types and How does browser cookies work

Most Internet users are familiar with the term “Cookie” but only a few know what exactly it is and the purpose it serves. This article will help you understand the working of different types of browser cookies in a simple and easy to follow manner.

To begin with, a cookie (also known as browser cookie, Internet cookie, web cookie or HTTP cookie) is a small piece of data that websites store on your hard disk in the form of a text file. Cookies allow websites to store specific information helpful to remember each visitor uniquely. A cookie is set when the user visits a particular website for the first time. Thereafter, each time the user loads the website the browser sends the cookie back to the web server so that it can keep track of the user’s previous activity.

Purpose of Browser Cookies:

The following are some of the common purposes served by cookies:

• Enable automatic user log-in thereby eliminating the need for a password input
• Enhance user experience by storing user preferences so that the site can look different for each visitor
• Keep track of items in the shopping cart
• Record user’s activity such as browsing history, click patterns, page visits and so on

Types of Browser Cookies:

Session Cookie

Since web pages have no memories, a visitor navigating to a different page on the same website is treated as an entirely new visitor. This is where session cookies come in handy. It makes it possible for the website to keep track of the user from page to page so that user specific information such as shopping cart data, account details and other preferences are not lost during navigation.

A session cookie is stored in the temporary memory while the user is on the website. If no expiry date is specified during its creation, session cookies are normally deleted by the browsers upon closure.

Persistent Cookie

A persistent cookie facilitates websites to track user settings and information when they visit the same website in the future. Unlike most session cookies, a persistent cookie does not get deleted upon browser closure. This makes it possible for the websites to easily authenticate users upon revisits without having to login again. In addition, persistent cookies help enhance user experience by storing their previous inputs such as language selection, themes and menu preferences.

Secure Cookie

A secure cookie has a secure attribute enabled so that its content gets encrypted every time it moves between the web server and the browser. This cookie is used only in the HTTPS mode and thus offers protection against cookie theft.

Third-Party Cookie

Third-party cookies are those that originate from a website other than the one that you are currently using. For example, when you visit a website www.abc.com, all the cookies that come from this website are calledfirst-party cookies. Suppose, if this website (www.abc.com) is running an advertisement on its page from a third party website www.xyz.com, then the cookie that originates from this website (www.xyz.com) is referred to as a third-party cookie.

Structure of a Cookie

A cookie is comprised of the following seven components:

1. Name of the cookie
2. Value/Content of the cookie
3. Domain associated with the cookie
4. Path for which the cookie is valid
5. Attribute to specify whether the cookie requires a secure connection
6. Attribute specifying whether the cookie can be accessed by a script
7. Expiry information of the cookie

The following snapshot shows the contents of Google’s cookie stored on chrome browser:

Drawbacks of Cookies

Even though cookies make our lives easier on the Internet, they come with drawbacks as well. Some of the major ones are listed below:

• Shared Machines: Most people share their computers with their friends and family. As a result, a cookie set during the usage of one user may not be appropriate for the other user using the same machine. For example, when a new user revisits a shopping website such as amazon.com, he/she will be presented with all the information belonging to the previous user such as order details, shipping address and other personal preferences. This may cause annoyance to the new user as he/she may be required to change all the preferences once again to match personal requirements. Additionally, the exposure of previous user’s preferences and settings to the new user may raise security issues.
• Accidental Deletion: In many cases, cookies can get erased accidentally when you clear your browsing history or use a third party cookie cleaner program. When this happens all your stored settings and preference gets lost and the website treats you as a completely new user.

Privacy Issues

Since cookies are capable of tracking a number of user specific information such as online behavior and personal preferences, they can be used to hamper the privacy of users. A website may use cookie information to display related advertising products based on your previous purchase. For example, Google often stores and uses your search keywords to display matching advertisements on all its partner network. Some sites are also known to have engaged in selling the cookie data to third parties which seriously hurts the privacy of individuals.

Credits : GoHacking – Srikanth Ramesh

How to test Reflected Cross Site Scripting Vulnerability

Welcome Friends! Today we will learn How to test that a web application is vulnerable to Reflected Cross Site Scripting or not. But before starting our tutorial, first of all we should know what Reflected Cross Site Scripting is.

Reflected Cross Site Scripting is an scripting attack which occurs when a hacker injects browser executable code in the HTTP response. The injection attack is not stored within the application itself i.e. not-persistant and only impacts those users who are tricked by hacker to open the malicious link via some social engineering methodology.

The executable attack string is added as a part of URI or HTTP parameters. Reflected Cross Site Scripting is also referred as non-persistant XSS or simply type 1 XSS.

If the application is vulnerable to Reflected XSS then it will pass unvalidated input sent through requests back to the client.  So in short we can say Reflected Cross Site Scripting Attack is an two step attack process where Step 1 is finding the vulnerable URI or HTTP Parameters and Second Social Engineering Step.

Most attackers use Javascript and VBscript for coding their exploits or payloads. Bla bla… I know you all will be interested in What hacker get doing Reflected Cross Site Scripting? Booomm…. Below is simple list that can be achieved using Reflected Cross Site Scripting:

• Install Keyloggers.
• Steal Session Cookies
• Stealing Clipboard Data
• Change the content of the Page (for example : download links, redirects etc..)

List is endless.. So now you guys must have understood why i am teaching you Reflected Cross Site Scripting.

So friends, how to identify or test that a URI or HTTP Parameter is vulnerable to Reflected Cross Site Scripting? Lets learn in detail with help of examples.

Reflection Cross Site Scripting identification involes 3 fundamental steps :

1. Identifying Input Vectors : Hacker has to identify all user defined variables and how to use them as input. This contains HTTP parameters, POST data, hidden form field values, and predefined radio or selection values etc.. You can use Inspect Element Feature(available in Chrome and Firefox web browsers) to find almost all of these parameters.

2. Analyze each input vector for possible vulnerabilites : This step is similar how we identify an XSS vulnerability i.e. hacker will test each of input vectors with specially crafted strings like below:

<script>alert(123)</script>

“><script>alert(document.cookie)</script>

You can use web application Fuzzer to test multiple such strings like we do in case of XSS.

3. Finalize the vulnerability and its real time impact : From above step we will get all the vulnerable URI’s or HTTP parameters. Now we have finalize the one’s which has realisitc impacts on web application’s security.

That’s all for today Guys! We will learn more about Reflected Cross Site Scripting in next tutorial with help of live examples and how to fix Reflected Cross Site Scripting vulnerabilities.