Josh-CO Dev

Solving the worlds problems one line of code at a time.


Leave a comment

Another basic way to defend against XSS attacks

Another mediocre way to defend against XSS attacks is to encode or “escape” any input before allowing it to be handled by the interpreter. Here is a basic example of how to handle this in JavaScript. Use the same html as our previous example, then just paste this functions into your scripts.js file and rename the submit button to correspond to the event handler.

    $("#btnSubmit3").click(function () {

        var htmlToRender = "Welcome to our site " + escape($("#inputName").val());

        $("#Content").html(htmlToRender);
    });

This will strip out any special character so that they are not handled by the interpreter. In the below example, I tried to enter the following code:

<script>alert('a')</script>Josh

And this was the result

%3Cscript%3Ealert%28%27a%27%29%3C/script%3EJosh

Before, we saw that this actually caused an alert box to pop up on the screen. Making this one simple change allowed the statement to be ignored altogether.

Much like our previous defense example, this will not give you defense in depth, but it will give you a basic level of security that you may have never even thought you needed.

Advertisements


Leave a comment

Incredibly Basic Cross Site Scripting Defense

In my last post, we talked about the basics behind cross site scripting (XSS) and how attacks are normally performed. To reiterate, a cross site scripting attack is essentially when an attacker causes your site to run unintended code. This can be done through several different mechanisms, but the most common is to use the forms provided on your website, things such as text boxes, search boxes, etc. Unless certain protections are put into place, these type of controls can allow unintended code to be ran.

Cross site scripting is the vulnerability that most attackers start with when they are testing a site, mostly because it is incredibly simple to test and execute. Let’s say you have a web form that is asking a user for their name, and then it writes their name to the screen. An attacker is not going to put in their name.

Here’s some HTML that you can try this with, please not that you will need to include jQuery to use these examples.

<!DOCTYPE html>

<html lang="en">
    <head>
        <meta charset="utf-8" />
        <title>XSS Testing</title>
        
        <script src="/jquery-1.8.1.js" type="text/javascript"></script>
        <script src="/Script.js" type="text/javascript"></script>
    </head>
    <body>
        <p>This form will allow for easy XSS attacks using the input element.</p>

        <p>Enter your name: <input type="text" id="inputName">&nbsp<input type="button" value="Submit" id="btnSubmit2"></p>

        <div id="Content">
        
        </div>
    </body>
</html>

This should give you a basic html5 page that does nothing but asks the user to enter their name and then provides a submit button.

Now, create a new javascript file named Script.js and include the following code.

$(document).ready(function () {
    //xss
    $("#btnSubmit2").click(function () {

        var htmlToRender = "Welcome to our site " + $("#inputName").val();

        $("#Content").html(htmlToRender);
    });
});

This should seem a lot like the previous article so far. We’re basically echoing their name back to the screen.
Now, a malicious attacker is not going to enter their name. Their going to enter something like this:

alert("haha, attacked!");My Name

If your site is vulnerable to XSS, the attacker will get a popup box saying “haha, attacked!” and their name will still get echoed back to the screen.

So, how do we go about defending against this? One very basic way is to use regular expressions (regex) to check the text before echoing it back to the screen.

Add this method to your javascript

    function checkInput(inputToCheck) {
        var checkedInput = inputToCheck.match(/(javascript|src|onerror|%|)/g);

        return checkedInput;
    };

This method simply accepts a string of text, and then runs it against a basic regex statement to check for items such as “src” or “<". Now modify your event handler.

    $("#btnSubmit2").click(function () {
        //alert($("#inputName").val());
        var input = $("#inputName").val();
        //var safe = input.text();

        var checkedInput = checkInput(input);

        if (checkedInput != null) {
            alert("Attack caught");
        }
        else {
            var htmlToRender = "Welcome to our site " + input;

            $("#Content").html(htmlToRender);
        }
    });

All we are doing is sending the input text submitted to our new method and seeing if there is a match against the regular expression. If there is, we throw up an alert box and we only echo back the input text if it is not a match.

This method is far from foolproof and will only give you a basic system for preventing XSS attacks. This will keep out kids that don’t really know what they are doing, but it’s no good against a real attacker.


Leave a comment

Basic Cross Site Scripting

I was playing around with some cross site scripting demos to help educate our company about the importance of application security and thought that I would share one of my demos here. For those of you that are new to this, Cross Site Scripting, or simply XSS, is a web based vulnerability that allows a hacker to insert their own logic into your application. Many developers are prone to this attack and don’t even know it. Let’s illustrate.

Here is some basic html:

<!DOCTYPE html>

<html lang="en">
    <head>
        <meta charset="utf-8" />
        <title>XSS Testing</title>

        <script src="/jquery-1.8.1.js" type="text/javascript"></script>
        <script src="/Script.js" type="text/javascript"></script>
    </head>
    <body>
        <p>Enter your name: <input type="text" id="inputName">&nbsp<input type="button" value="Submit" id="btnSubmit"></p>

        <div id="Content">

        </div>
    </body>
</html>

If you know html, there is nothing crazy here. This just creates a simple form that has the text “Enter your name”, a text input, and a submit button. In my jquery call, “scripts.js” as linked above, I have this function:

    //xss
    $("#btnSubmit").click(function () {
        //alert($("#inputName").val());
        var htmlToRender = "Welcome to our site " + $("#inputName").val();

        $("#Content").html(htmlToRender);
    });

Again, pretty simple. This is a button click event handler on the submit button. All it does is take the user input and outputs it to the screen. This is what a lot of the internet does. Perform a search? It does the search and then outputs what you put in the search box to the screen. Same principle here.

What this is expecting is for a user to enter their name. Well, what if they enter something mischievious such as “<script>alert(“ha, I hacked your site”)</script> Josh”? Using this code you can try it. You will get an alert box that reads “Ha, I hacked your site”. But if you look at the screen after you click ok, it will say “Welcome to our site Josh.” This is actually one of the first tests that you make on a site to see if they are susceptible to XSS attacks.


Leave a comment

OWASP Top 10 for 2013 has been Released

The OWASP top 10 for 2013 has been released HERE. For those of you who are not familiar with OWASP and the top 10, if you are in IT Security or Development, you should be. Here is a brief description from OWASP.

The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. Versions of the 2007 and 2010 version were translated into English, French, Spanish, Japanese, Korean and Turkish and other languages. Translation efforts for the 2013 version are underway and they will be posted as they become available.

We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.

Just like usual, injection is at the top of the list.