Josh-CO Dev

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


Leave a comment

Target Data Breach Confirmed

Long story short, Target has confirmed a massive data breach of their credit card data. It doesn’t look like any statistics have been released yet, but usually in cases like this it affects all customers that have paid with a credit card.

http://www.usatoday.com/story/news/nation/2013/12/18/secret-service-target-data-breach/4119337/

Advertisements


Leave a comment

Tools – SQLMAP

I decided to start sharing some of the tools that I use on a daily basis to perform my job, and one of my favorites is SQLMAP. SQLMAP is a command-line tool that is used for automatic SQL injection and database take over. It is built in python so it is available for any operating system that can run python.

The tool itself will support MySQL, Oracle, Microsoft SQL Server, MS Access, SQLite, and a few other database systems. Basically, if an application is important enough to have a database, SQLMAP can attack it. The tool can hit a url, a direct connection to the database, log files (such as Burp), config files, and many others. There are options to support proxies, cookies, specify injection points, etc. For a full list of options a switches consult the user manual.

It is also a great tool to use for demos. Quite often, I am invited to management level meetings to talk about application security and why it is so important. Like many things in information security, nothing is quite as convincing as giving a live demo.

If you would like to learn more about the product, go check it out at http://sqlmap.org/ or the github project at https://github.com/sqlmapproject/sqlmap.

Please note that using this tool against any database that you do not own would generally be considered illegal. Please use at your own risk. There are several platforms that you can download to test a tool like SQLMAP in your own environment, such as SQLOL or DVWA but we will leave that discussion for a later time.


Leave a comment

SQL Injection with SQLMAP – DerbyCon 2013

Here is a great video from a presentation I attended at DerbyCon 2013 this year. It is a video demonstrating how to use SQLMAP to attack the SQLOL database and has a lot of good information. Later on, I will post some videos and demos of how to install this, make it work, attack the database, etc. Credit goes to Conrad Reynolds for putting together this presentation.


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.


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.