OWASP Attacks Part 3 Injection

Moved to New Site

This is the subject with the widest breadth. I'll not be able to cover every kind of injection attack out there, but I will still mention them so you can look them up if you are curious, but the subject of injection will probably span a few posts.

SQL Injection
This occurs when query parameters are acquired from the end user and they contain characters that will cause the SQL command to execute in a way that it was not intended.

Lets have an example, here is a little query:
select `social_security_no` from `sensitive_table` where `user_name` = 'jclark' and `password`= 'superSecret';

What would happen if someone created a user account with some non-alpha-numeric characters?
Something like user name = "*';--";

select `social_security_no` from `sensitive_table` where `user_name` = '*';--' and `password`= 'passwordPants';

Here you see the user name, with it's unescaped characters, will have a big impact on how this query executes.
The system will now select all the SSNs where username is equal to a wildcard character, and the -- will comment out the rest of the query.
So it will effectively return all the SSNs stored in the table.

There are several methods that can be used to help protect your queries.
Regular Expressions, PHP's PDO, PHP's addslashes(), .NET's  SqlParameter Class, and many more.

Blind SQL Injection
The term is derived from the fact that you may not be printing the data returned from the query out to the page, but the query is still running.
Check out the following pseudo-code:

try{ 
    sql_command = "select * from table where parameter='parm_from_url'";
    if(execute(sql_command)!=null)
        LoadPageOne();
}
catch(Exception ex){
    //show 404 page
}

You can see here that even though a page doesn't show data that is returned from the SQL command directly, there is still the indirect knowledge that is gained by which page loads. This allows an attacker to ultimately ask your database true or false questions.
Although slow, it it still a data leak that could lead to ruin.

Comment Injection Attack
Comment commands in code are super handy for developers, but if input from end users isn't properly parsed, large chucks of your code could become a comment and not run correctly anymore.
The goal of this attack is to get a program to disregard a portion of itself as a comment, causing a huge variety of outcomes. The goal usually is to bypass parameter sanitization 

We touched on this a little above. With the -- MySql comment character. There is also #, ,  and /*, for the different flavors of SQL. These will truncate the the rest of the SQL command so that the attackers query can execute without worrying about providing data for the rest of the parameters.

The PHP comments // and /* can cause problems if not properly escaped,i.e. \/\/ or \/*.

The most common one I've seen is an inability to handle the HTML comment opening tag <!--
Nothing gives me more join than dropping this meatball in a form and then seeing the page stop rendering half way down after submission.

Be sure to test your URL variables, form information, and even cookie information before allowing it to leave its dirty makes on your code and database. 

Nikto - Kali

Moved to New Site

Intro
Nikto is a, non-stealth, web vulnerability scanner. So don't think the NSA doesn't know you are using it. This tool is easy to get some quick results, so I especially recommend it to beginners.
The real charm of nikto is that most positive results come with the layman's description and a link. (Read the contents of these links to become better at life.)
You can initiate your first scan with this command

nikto -h <IP or Host name>

Lets see what we get!

First line is a finger print of the server's operating system. Sometimes you get very specific info, sometimes you don't. Obviously we didn't get very specific data here.

Next is the header scanner, cookie scanner, standard stuff.
The next line of real interest, and I wish they made it stand out more, is:
Web Server returns a valid response with junk HTTP methods, this may cause false positives.

Be sure to keep an eye out for this line. This usually means the site is using some type of url route functionality, ie ng-route or $.route/$.Observe.

Then when the fluff clears, all that is left is a field of OSVDB numbers. I know I have not discussed OSVDB before, but you can check it out here. http://osvdb.org/ To be brief, they are well known and well used repository of vulnerabilities and I will probably give them their own blog post in the future.

But for today, just know that each of those numbers can be used at osvdb.org to find an in depth explanation

Nikto Options

An exhaustive list of nikto commands can be found here: https://cirt.net/nikto2-docs/options.html

But I'll talk about some of the more interesting ones here:
nikto -evasion 8 -h <IP or Host name>

There are some different evasion options available to you:
1: Random URI encoding (non-UTF8)
2: Directory self-reference (/./)
3: Premature URL ending
4: Prepend long random string
5: Fake parameter
6: TAB as request spacer
7: Change the case of the URL
8: Use Windows directory separator (\)
A: Use a carriage return (0x0d) as a request spacer
B: Use binary value 0x0b as a request spacer


nikto -no404 -h <IP or Host name>

no404 disables 404 checking and will help keep your scan from becoming a DoS.

nikto -Tuning 4 -h <IP or Host name>

Not looking to throw the book at a target? You can use the tuning options listed below to waste less time and only scan what you are interested in:
0: File Upload
1: Interesting File / Seen in logs
2: Misconfiguration / Default File
3: Information Disclosure
4: Injection (XSS/Script/HTML)
5: Remote File Retrieval - Inside Web Root
6: Denial of Service
7: Remote File Retrieval - Server Wide
8: Command Execution / Remote Shell
9: SQL Injection
a: Authentication Bypass
b: Software Identification
c: Remote Source Inclusion
x: Reverse Tuning Options (i.e., include all except specified)