{"id":1346,"date":"2018-04-02T09:06:00","date_gmt":"2018-04-02T09:06:00","guid":{"rendered":"https:\/\/www.htmlgoodies.com\/uncategorized\/so-you-dont-want-to-be-hacked-with-cross-site-scripting-xss\/"},"modified":"2021-04-23T20:13:03","modified_gmt":"2021-04-23T20:13:03","slug":"so-you-dont-want-to-be-hacked-with-cross-site-scripting-xss","status":"publish","type":"post","link":"https:\/\/www.htmlgoodies.com\/html5\/so-you-dont-want-to-be-hacked-with-cross-site-scripting-xss\/","title":{"rendered":"So You Don’t Want to be Hacked with Cross-Site Scripting (XSS)"},"content":{"rendered":"
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.<\/p>\n
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:<\/p>\n
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.<\/p>\n
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<\/em> site!<\/p>\n 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!<\/p>\n 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.<\/p>\n 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 &, 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 You can then later chose to use 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.<\/p>\n 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 If you find that you need to use 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.<\/p>\n 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:<\/p>\n Clearly this text could have bad consequences on your site if it were placed within a comment tags.<\/p>\n With this text, you might find that a message saying, “Hi Mom!” displayed on your page!<\/p>\n 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!<\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":24,"featured_media":1348,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[30683,30618,30625,30645],"tags":[4232,2723,3385,5287],"b2b_audience":[29,37,34],"b2b_industry":[],"b2b_product":[68,94,67,113,114,116,117,98],"acf":[],"yoast_head":"\nTip 2: Validate, then validate again<\/h2>\n
Tip 3: Get rid of dangerous characters!<\/h2>\n
<<\/code>, 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:<\/p>\n
\n
Use; <<\/li>\n
Use: ><\/li>\n
Use: '<\/li>\n
Use: "<\/li>\n
Use: /<\/li>\n
Use: &<\/li>\n
Use: `<\/li>\n<\/ul>\nTip 4: Check URLs before trusting them<\/h2>\n
encodeURIComponent()<\/code>. This will replace the dangerous characters with escape values.<\/p>\n
var uri = \"http:\/\/www.htmlgoodies.com\/mytest?alert('stop it!');\"\nvar res encodeURIComponent(uri); <\/code><\/pre>\n
decodeURIComponent()()<\/code> if you want to get back to what the user provided.<\/p>\n
uri = decodeURIComponent(res); <\/code><\/pre>\n
Tip 5: Treat user submitted text as text, not mark-up<\/h2>\n
innerHTML()<\/code>. Instead you should be using
textContent()<\/code> or
innerText()<\/code>.<\/p>\n
innerHTML()<\/code> to display user submitted text, then it is critical that you verify that all the text uses escaped with no markup within it.<\/p>\n
Tip 6: Be careful where you put a user’s data<\/h2>\n
usertext = \"this is text that could be add within a comment to say \"--> Hi Mom! <!--\" when you might not have intended it to! \"<\/code><\/pre>\n
<!-- this is text that could be add within a comment to say \"--!> Hi Mom! <!--\" when you might not have intended it to!--!> <\/code><\/pre>\n
In Conclusion<\/h2>\n