Secure Your Web Application With OWASP

What Is Cross-Site Scripting?

Cross-site scripting attacks are made to take over your browser.  A hacker that accomplishes this has access to your cookies and sessions which can hold sensitive data!  This culprit can also make unauthorized changes to the web application and create links that will take you to malicious sites! 😱

Attacks Using XSS

So how does it work?  The outlaw trying to take over your browser creates a script that is injected into the web application.  

That’s right! 😉

HTML forms just like with SQL injection!  A script can also sneak in through the URL, HTTP header, and other parts of your framework.

Unlike the SQL injections, it isn’t SQL queries and commands on a database. In XSS,  a sinister script executes on the code in the web application. Let’s look at some javascript XSS attacks.

Let’s go back to the login page for the username and password. Instead of the username, the hacker will type in:

<script> I haxx000red you </script>

On a login page that’s not secure, there will be a pop-up box executing this code. On top of that, the URL now in your address bar can be used to execute that script directly. There’s another way to do it by loading an HTML image. You will see that the pop-up can work as a customized error code!

<img src oneerror= “alert(haaxxxx000red 4ever!)”>

The URL in the address bar after the script is executed may show up as something similar to this:

webdevfightshacker.bla/index.html?query=<img src + onerror%3Dalert%45%haaxxxx%87”....>

Notice that the domain on the URL looks legit, but the end of it has the script tacked on to it.   That hyperlink can execute that code on the browser. A hacker can provide the innocent clickster this URL to run the XSS attack in other ways.

XSS attacks also target cookies, exposing the contents in a pop-up. For example, if you’ve sent a login request to a web server, and it responds with a cookie with your credentials in plaintext. The XSS script will execute on your browser showing a pop-up with your credentials that were on the cookie.

One option is to add an HttpOnly flag to your cookies, which is available in every language. It does not allow the script to access the cookie. HttpOnly is a flag to set to true in most of the frameworks. For example, Node.js has a cookies module with HttpOnly, and a middleware called Helmet. Express PHP has a setcookie() function that allows HttpOnly as a parameter, and ASP.NET has the CookieHTTpOnly and CookieSecure option.

Here is the good news.  XSS attacks have gone from the number three slot to number seven in the OWASP Top Ten because browsers have amped up their security, making these attacks more difficult.  However, that doesn’t mean that you as the web developer can write your code free of worry from XSS attacks. You still have to do your due diligence. 😊

Here Are Some Ideas:

• Input validation - you may remember this oldie but goodie from the injection attacks.  Same principle applies here where you blacklist certain characters like the script tags < “ and strings like <script>.

• Input transformation - you can encode all of your input to an HTML character entity or text so it doesn’t execute any scripts.  There are simple functions and libraries that can help you encode all of your HTML and Javascript.

• Set your cookies to HttpOnly.

• Research  and implement XSS security based libraries for your framework.

What Is Cross-Site Scripting Forgery (CSRF)?

A hacker can create an XSS link and distribute it through social engineering to gain access to a user’s browser.

If the user clicks on the link while a session is still open on their bank, the hacker can hijack a session token in the browser (in real time) to access that bank session.

The hacker will not create requests without the knowledge or consent of the user that is currently authenticated! These requests can also lay dormant until the user has created a session on their browser.

Remember how some requests retrieve information, and some make changes? The requests in a CSRF attack usually make changes, and it is already filled out by the hacker. Take a look at this example GET request:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

This XSS link can be a fully formulated GET or POST request form that makes a bank transaction.

The funny thing is that this bank transaction occurs unbeknownst to the user who may or may not even realize that the browser still has the bank session open.  

How Can I Stop the CSRF Madness?

1. Require re-authentication for requests.

2. Use a unique token for each request.

3. Use anti-forgery tokens which validate the client-side token to the web server-side token.

4. Research the CSRF security based libraries.

Let’s Recap!

• Cross-site scripting is a script that can be executed in your website.

• Prevent XSS with input validation and input encoding.

• Protect your cookies by setting the HttpOnly flag.

• CSRF attacks can happen with social engineered links.

• CSRF attacks perform transactions without the user knowing.