Josh-CO Dev

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


Leave a comment

Defending Against Cross-Frame Scripting

Another type of attack that we haven’t talked about yet is cross-frame scripting. A cross-frame scripting attack is where an attacker will take a page of your site and embed it in an iframe. Some simple css can then be put in place to make it look like the site is actually yours rather than looking like an iframe. This might seem pretty harmless, but the hacker could include some malicious scripts to do things like capture the keypresses and send them to a web service on their real site. Some really good information can be found at OWASP.

Modern day, this attack is a bit trickier to pull off as cross-domain communication is generally blocked and it takes quite a bit of work to get around this. That being said, it can be done so you should treat this as a real threat. This also becomes a bigger insider threat as I could write an app that includes another dev’s site and then steal user credentials that way without having to worry about cross-domain issues.

So, how about the defense. Ready for this?

<META http-equiv="X-Frame-Options" content="Deny" /> 

That’s it! Just put that html in the header of your application and it will prevent your site from being rendered in an iframe!


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.


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.