Security Vulnerability – XSS Attack

To build a web product and run it locally is easy. To deploy and make it public to the world is much more difficult. One of the difficulties we must face is the possibility of our website being hacked by millions of hackers surrounding the world. Therefore, knowing how to deploy is one thing, but knowing how to avoid being attack by all the bad guys is much more important. Day by day, hackers try to scan every hole in the security wall to attack the website. Therefore, as a developer, we are also a protector of our children, need to improve our knowledge of security. This series aims to identify some popular vulnerabilities a web product may encounter.

Part 1: SQL Injection

Part 2: XSS Attack

Part 3: Password Management

Part 4: CSRF and “Silhouette” Threat

---

The next security vulnerability I want to write about of course is XSS Attack, another popular security hack. XSS is the short term for Cross-Site Scripting, a vulnerable point usually happen in the app where users can interact with each other.

So what is XSS Attack?

We know that to let users see the web page, the browser will try to render the HTML file. The idea is in this HTML file, there is some evil thing called Javascript, which usually enclosed by <script/> tag. So when the browser sees this, it will notice this is a Javascript function, and try to execute it. This is where the hacker can exploit.

Let’s take an example with Facebook. We know this is a place where user can post their status, and other people can see it.

So hackers can try to post some Javascript script in the status or comment section here. For example, he can type

<script>alert("You are hacked")</script>

And when it returns in your device, it will auto-execute because of the browsers. As a result, a popup will display.

Of course, this not really happen in FB. They already knew that.

There are 3 main types of XSS:

Stored XSS: This is quite simple, this is the XSS that is stored in the server. Same as the example we mentioned above. When a user posts a script, that script will be store in the application server database. All friends of this hacker who gonna see this status – which is fetched directly from the database, will autorun the script function. This is why this kind of XSS can create a huge impact because it can spread so easily.

Reflected XSS: This XSS is activated when a user clicks on a link. So the idea is hacker will try to embed the script into a malicious link (usually porn link, this always works !!) When the innocent user clicks into the infected link, the hacker then can steal their credentials or take over the control of their browser. So this attack usually not target directly the server like Stored XSS, but usually directly to the user (maybe though email). The website has this vulnerability when there is a page that takes the content(params, query) from the URL to display in the page body.

DOM-based XSS: This actually very similar to Reflected XSS. The small difference is only in Ordinary Reflected XSS, the malicious script is executing from the server response, whereas DOM-based XSS is executed when the browser tries to update the DOM with the new response.

Fun fact: This XSS attack is so popular, it happens not only in small websites, but even in giant applications (like FB – but not in the status update like our example). A lot of white-hat hacker around the world has reported some XSS attack to FB, and usually, they got in return a bounty.

Big Companies also encounter this

How to prevent XSS?

Escape Dynamic Content: All information that is inputted by the user should be processed to escape all potential characters. We can also choose to filter out all dangerous terms.

Whitelist Values: This means that we only accept some input values from the user. There are a lot of ways to implement this, however, I want to write a method coming from the Web UI Design point of view. For example when we want to ask a user to input their Country, instead of a blank input box, maybe can replace as a dropdown to only accept some values. This will not 100% xss-proof, but of course, it will help to avoid.

All of those methods above together are called sanitizing user input.

Content-Security Policy: Nowadays, browsers have this policy to restrict which Javascript function can be executed (based on their origin). And it is so easy to set just by a meta HTML tag. Trusted-type is one of the policy can be used here.

X-XSS-Protection: Adding this built-in XSS precaution to the server response to activate the protection.

Trusted-type and X-XSS-Protection can produce conflict in your code when using, so only use them when you know how to handle and understand them properly.

Fun Fact: Since this is so popular, some modern frameworks(Spring, Django, ASP.NET MVC) already integrated inside the way to prevent. However, I’m not sure about PHP…