Tuesday, September 27, 2022

So You Don’t Want to be Hacked with Cross-Site Scripting (XSS)

If you are creating a site that allows users to enter information, then you need to learn how to avoid some basic mistakes that can leave your site vulnerable to being hacked. The first step to avoiding Cross Site Scripting (XSS) attacks is to know they can happen.

In short, if you are allowing any information to be added by users to your site, then you need to make sure you are protecting yourself. Some of the user interactions that pose a risk include:

  • Allowing for comments
  • Allowing image, article, or file submissions
  • Using Form submissions
  • Allowing data to be imported from other sites — such as allowing YouTube videos or Facebook posts to be pulled into your site.
  • User registration and logins
  • Accepting and using added parameters on the web address

If you are doing any of these things, then you should make sure your code is secure. The following are a few tips to make your site more secure.

Tip 1: Don’t accept anything from unknown users

If you don’t have a way to validate or know who is entering content onto your site, then you should think very seriously about whether you should allow commenting at all. This is why many commenting systems require registration before you are permitted to post. If you can’t trust a user, then don’t let them add content to your site!

Tip 2: Validate, then validate again

It is easy to know that you should validate what is entered when the user is filling out a form on your site and performing validation to check what is being entered is, generally considered, common sense. If a person is entering a phone number, you can check to see that it is a phone number using JavaScript on the page. Validating on entry on the client side is great, and you should be doing that!

If that data is also being stored on your web site’s server in a database or otherwise, then you should also validate the data on the server side. You should always verify that what you are receiving on the server is what you expect and that it hasn’t be changed or that someone isn’t sending something directly to the server from outside of your web page. Validate again.

Tip 3: Get rid of dangerous characters!

There are certain characters that are more dangerous than others. For example, the letters in the alphabet (A to Z) are generally safe. Characters such as &, <, and quotes; however, are a bit more shady. These characters mean something in HTML, so you need to make sure they don’t get treated like HTML. The easiest way to do this is to encode the characters when they are used in text submitted by users. Some of the characters you should watch out for are:

  • Don’t use: <
    Use; &lt;
  • Don’t use: >
    Use: &gt;
  • Don’t use: ‘
    Use: &#x27;
  • Don’t use: “
    Use: &quot;
  • Don’t use: /
    Use: &#x2F
  • Don’t use: &
    Use: &amp;
  • Don’t use: –
    Use: &#x60;

Tip 4: Check URLs before trusting them

If you are allowing links to be added by users, then you should make sure they do not contain anything that could cause problems. For example, if you store bookmarks, or if you have links to profile pages that might be based on a user name entered, then you might be opening a vulnerability. One way to provide protection is to make sure that any URLs that have user input are treated with encodeURIComponent(). This will replace the dangerous characters with escape values.

var uri = "http://www.htmlgoodies.com/mytest?alert('stop it!');"
var res  encodeURIComponent(uri); 

You can then later chose to use decodeURIComponent()() if you want to get back to what the user provided.

uri =  decodeURIComponent(res); 

Tip 5: Treat user submitted text as text, not mark-up

It might sound goofy to say treat text as text, but it isn’t! When you put information on your webpage, you end up using HTML. There are commands in JavaScript for displaying HTML, and then there are commands for displaying just text.

When displaying text that was created or saved by a user, make sure it is always displayed as text. You can do this by using text commands and by avoiding HTML display commands. In your JavaScript, you should avoid displaying any user data using innerHTML(). Instead you should be using textContent() or innerText().

If you find that you need to use innerHTML() to display user submitted text, then it is critical that you verify that all the text uses escaped with no markup within it.

Tip 6: Be careful where you put a user’s data

Stating the obvious, don’t put data from users you don’t know or trust into dangerous areas of your site. For example, don’t accept user data and place it within a script block, within your CSS, within an attribute on an HTML tag, or even within an HTML comment.

As an example, it might seem harmless to put text in a comment, after all, it is just a comment. Consider the following text, and think about what it would do in a comment if it isn’t encoded correctly:

usertext = "this is text that could be add within a comment to say "--> Hi Mom! <!--" when you might not have intended it to! "

Clearly this text could have bad consequences on your site if it were placed within a comment tags.

<!-- this is text that could be add within a comment to say "--!> Hi Mom! <!--" when you might not have intended it to!--!> 

With this text, you might find that a message saying, “Hi Mom!” displayed on your page!

In Conclusion

This list of half a dozen short tips can help to improve the security and safety of your site by defending against cross-site scripting attacks. If you leave your site vulnerable to XSS sites, then you risk not only having your site display changed, but also the possible loss of data that could result in even larger problems. The one tip above all others is that if you are accepting user input or data from outside of your control, then you need to validate it before you do anything with it!

Popular Articles