WWCode Talks Tech #17: Web Security Basics

WWCode Talks Tech #17: Web Security Basics

Written by WWCode HQ

Uncategorized

Women Who Code Talks Tech 16     |     SpotifyiTunesGoogleYouTubeText
In this web security walkthrough, Angela Saccone, Community Manager at MetaCTF, discusses cross-site scripting (XSS) and web security methods, such as HMTL entity encoding, using JavaScript to protect websites from cyber-attacks.

The first thing we will talk about is what web security is in a nutshell. It's about protecting our websites by using security methods so that they will not get compromised by malicious users and or attackers. When we have web vulnerability, it can prevent business operations. I want to first talk about Cross-Site Scripting before we get into sHTML encoding. Cross-Site Scripting, also known as XSS, can do critical damage to a website. It can deface a website. There are so many different things that Cross-Site Scripting can do.

We will look at some examples by OWASP of what Cross-Site Scripting looks like. It's typically with the script tag, and then within the script tag, you have things like on mouse, over events, alerts, click me, on error and you have the image source, and you have a URL, and then you have it on error alert. That can be malicious because you can put anything inside the tags that can cause critical damage to a website, even with encoded URL schemes. These are just a few examples of what we'll deal with regarding HTML encoding. Also, whenever you see something with 'element.innerHTML', it can be malicious because you can put whatever you want inside as an attacker.

When you think about what the attacker can do, they can put different types of payloads and the script. We don't want that to happen. I made a little illustration for those who have not had any familiarity with HTML, CSS, and JavaScript. If you don't know much about HTML, there's something called an element ID that you can assign to text. When you use inner.HTML, this is with JavaScript, you can assign that ID, that text there, that you had assigned to the HTML element ID. It can be assigned to some element, and you have a semicolon. This is how they would communicate with each other using HTML, CSS, and JavaScript. 

We can use your HTML entity to encode common characters. Here, it gives you different types of prevention for Cross-site scripting. There are things like the HTML elements like div tags or bull tags, and you can use different safe syncs that will automatically encode the HTML. So that script tag you see here &lt or ampersand lt with the semicolon, and then you can use ampersand GT the semicolon at that part of the script tag. That way it doesn't activate when there's some type of attack trying to happen. And depending on what else is in the div tag or other HTML tags, you can use the dollar sign, et cetera. 

I want to show what I mean by the HTML element with JavaScript. And for this example, I want to use the h2 element or heading two element secret. As of right now, it looks like some random, plain old heading two, but there could be a script inside here. The script tag is the same on CodePen and other ones where you have '.js file'. When you have this script tag, it's going to communicate with div ID equals the secret. This secret is what we assigned. We gave a name for the div. We used '.innerHTML', and we assigned it to the secret tag. This can be malicious because you can put whatever you want inside with innerHTML. How do we mitigate this? We can use the OWASP, the &lt, and the &gt. We can't use a slash for escaping things in JavaScript. This can set HTML inside the element. 

When this is activated, the secret tag will drastically change. It's going to look more like a text. It's going to be encoded. It's still the '.innerHTML', but we stopped cross-site scripting from happening by following the OWASP XSS prevention sheet. You can also do this in the browser with web devtools. When you encode this, you can also see this actual text too, as output when you're using JavaScript. You can make a function with this. It doesn't have to be just one line. The reason why it's safer and a better way to use '.innerText' over '.innerHTML' is because this will be just strictly text. It will not be some link that somebody can click on, and it could be some type of XSS or a cross-site scripting attack. It's a safer and more secure method. It's going to stop all that input that's going on within the heading two-tag secret.

Another example, we're going to be using the ID secure text. This time it's going to be in a paragraph tag. Anybody, especially the attackers or malicious users, can put anything that's going within the paragraph tag and do some malicious things. When you click something, something could happen, like an XSS attack. This is another example of cross-site scripting. When you click on 'click me', it will come up with an alert message. It would bring some on-air alerts and it would delay the website, and that's not good.

Another thing we have going on is something called the input type button, then click me, and then the class button on click. This is key, and it's with the function called a secret escape. The function is where you can store all of the code that you want that will make whatever you want it to do, such as storing variables, doing decision-making, Excel statements, etc. So We have a function with secret escape. I coded it this way, and it's not the traditional way. There's more than one way to solve the problem. I want to use 'document.getElementById.securetext.innertext', innertext is one of the best things you could use. The site is secure. That's not the problem. The problem is within this function, there's some type of script alert that could be an XSS attack. 

I'm not going to get into the details with let versus var, but we assigned it to a variable called secret and stored a script. We have script tags within script tags. We assigned my div because it was with div we created a div element, and then we used inner text, and we assigned it to secret. We were storing the variable with a div that we made in secret, and we just used that to stop the XSS attack. For educational purposes, I just want to use another variable to store what was here. I want to show you can still use innerHTML because it's used extensively in JavaScript within the web development community.

I'm not saying you should never use it, just use it wisely and securely. Make sure that things are encoded and make sure things are sanitized. That's what we're doing, we're sanitizing things. I wanted to show people what that variable did, to show that we did some encoding. When I click the "click me" button, it should show how this script is encoded. It's going to say, "yay is secure now." Don't get all caught up with that. It's the click me the part I'm trying to stop, the XSS, the button we had. We stopped the alert and encoded it using '< script." It's not activated because we stopped it by encoding it. When you are doing HTML encoding with JavaScript, you don't have always to write it as a function. You can use the arrow function, a one-liner way of writing what you want to do with the functions.