SQLI-LABS SERIES PART-17

SECOND ORDER INJECTIONS

Second order injections are the ones which are not widely discussed. Firstly these cannot be detected by  tools and one needs to understand the application logic and flow to detect this. A code review is better to understand the injection.
In general the Injections happen when the developer trusts the input/or fails to sanitize input  to build up  the query being used in the application.

What are second order injection?
Second order injections can be considered simmilar to the stored XSS. Injection does not directly yeild result but this injection is used at some other places insecurely causing the injection to trigger and yield results.
As an Example to understand this imagine an application which allows user to create a user account in the system. Now a malicious user can try to inject SQL keywords in the user creation form which is nicely escaping dangerous characters by use of mysql_real_escape_string() and making it safe for that form. Because mysql_real_escape_string() escapes the dangerous chars, therefore if attacker tries to inject admin' OR 1=1--  in the username field, because of the function, the quotes would be escaped and input would become admin\' or 1=1--. If other values of form are valid, the user account is created with the name admin' OR 1=1-- .

Now with the user created, he can login with newly created account and go to the password reset page. As this page is checking for old password , and building up a query behind the scene something like
UPDATE users SET passwd="New_Pass" WHERE username="Username" and passwd="oldpassword"

Now as the username is being taken from the database, the developer treats this as trusted info. As he is confident that initially there is no SQL Injection on the pages. This blind trust on the data from database is called without any escaping, thereby causing the username to trigger the SQL injection.

The query becomes UPDATE users SET passwd="New_Pass" WHERE username ='   admin' --  ' AND password=' old password  '.
Effectively SQLi working and changing the password of Admin user commenting out rest of query which is marked in brown

A video demonstration for the same can be found on the location below.

HAPPY DIWALI

HAPPY DIWALI TO EVERYONE

May This festival of lights bring all the happiness and joy to you and your loved ones.

SQLI-LABS SERIES PART-16

SQL Injection via COOKIES

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.

As we discussed before in the earlier posts, enumeration is the first and very essential part of every penetration test. Knowing the workflow of application is trivial to its testing. The more one knows about the application, the better and effective it becomes. 

Secondly, all input parameters should be tested. These do not include just the form fields, but also the other input fields like the referrers, user-agent, cookies. Developers these days take care to sanitize the the form inputs and take extra care for those but forget to pay the same attention to the other inputs.

We discussed the injection in update query and injection in the headers in our previous lessons. In  this lesson we will discuss the injection via cookies. 

Technically speaking, it is trivial to understand, how cookies are being generated by application and how the same is used within application. Understanding the cookie generation logic is trivial to the successful testing.

In Less-20, we introduce the basics and use a clear text cookie generation logic to explain. There is no difference in how the injection is performed via a cookie or any other form parameter. In Less-20 and 21 we deal with error based injections.

Less-21 uses an encoded cookie value and the application logic is used to encode and decode the data and use the result in the queries later on.

Because both are error based based injections, and the database is interacting with the webpage, therefore we can use union statements to dump the databases or we can use the double query injections for dumping the database.

For enumerating the application, we first try to see the workflow off application by providing a legitimate input.

This successful login places a cookie in the user browser with Key value ==> pair. Cookie name uname and value as username. 

This cookie value is then used to retrieve some information from the database causing the vulnerable injection point.

Using firebug, tamperdata or any interceptor proxy like burp suite, ZAP (Zed Attack Proxy), web scarab or any other similar, we can modify the cookies and inject in our payloads. Fuzzing the cookies, we observe that sql query breaks and mysql error is displayed on the screen.

Once we achieve this error, then this can be considered similar to error based injection and proceed accordingly to dump the database.

For Less-21 we observe that the system is using Base64 encoding scheme to send an encoded cookie to the browser. Hence forth we need to encode our injections using Base64 to be consumed nicely by the web application.

You can watch the video demonstration on YouTube.

SQLI-LABS SERIES PART-15

INJECTION IN THE INSERT QUERY

INJECTION IN HEADERS

In the earlier parts of the series we looked at the GET and POST based injections and dived into details on error based SQL Injections (string type, Integer type), Double Query injections error based, Blind injections (Boolean based and Time based) or use the outfile/dumpfile to dump the info in text files . In this part we would look at the injections in the Insert Query. For this we would look at the Less-17.
A general update query looks like

INSERT INTO table (col1,col2, col3) values (val1,val2, val3);

For the purpose of the lab, we would be using the Less-18 and Less-19. These are different Lessons as the injection is in the insert Query and that to in header fields. The Less-18 talks about the injection in the "useragent" field and the Less-19 talks about the injection in the "referrer" field.

"Less-18 - INJECTION IN THE USERAGENT FIELD"

"Less-19 - INJECTION IN THE REFER FIELD."

For the purpose of fuzzing these input points we need to write a script or use interceptor proxies like Tamper data (add on for Firefox), Burp suite, Fiddler, Zap, or any other tool which allows you to modify the headers on the fly.

These sort of injections where the Header fields are being inserted into the database, our focus is to check if the data can be extracted from it is certain way. Well blind is always an option and we can use Boolean or time based injections. The process works but is overall slow.

In cases where MySQL errors are displayed by the application, this can be used to dump the values efficiently and with much lesser number of queries as compared to Blind based. The logic of Double query injections is used to dump the info.

For more details and basics of the double query injections watch the other parts of the series.
the complete list can viewed here http://www.securitytube.net/user/Audi or directly watched on youtube at http://www.youtube.com/channel/UCiOdrhE67CR8lM0z2-_fe-A/videos

SQLI-LABS SERIES PART 13

INJECTION IN UPDATE QUERY

In the earlier parts of the series we looked at the GET and POST based injections and dived into details on error based SQL Injections (string type, Integer type), Double Query injections error based, Blind injections (Boolean based and Time based) or use the outfile/dumpfile to . In this part we would look at the injections in the update Query. For this we would look at the Less-17.

A general update query looks like

UPDATE TABLE SET PARAMETER-1="some value" WHERE  PARAMETER-2="some value";

In the general case, a front end for a password update or profile update would have this query working in the backend. During a pentest be extra careful while handling these queries, because one wrong test can update the complete production database with wrong values.

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.

In the update statement injection, our objective is to extract info and not update the database, therefore we can use the the basics of

• Double query injection
• Blind injection
• Dumpfile/outfile to extract the information.

Basic query injections:
Less-17 Line number 97
$update="UPDATE users SET password = '$passwd' WHERE username='$row1'";

CONFIDENCE BOOSTER DOZE

Thanks a ton to everyone who are watching/following the videos series closely and also appreciating it. Another link on Facebook posted by Vivek Ramachandran, I am really really touched with the wonderful words from the Guru himself..... thanks a ton.

SQLI-LABS SERIES PART 12

In the last part we started to explore the error based sql injections in the POST parameters. We were able to use the UNION statements to dump the database of the test bed. In a situation when the database does not interact with the web page and only was the database displays some info on the web page is through the mysql errors. Then in this case the fastest way to extract the info is through use of type caste errors involving sub queries also referred to as double queries, but MYSQL is very flexible and returns empty rows rather than throwing an error, so infosec guru's figured out some combinations of functions, if combined make sql queries which pass the compile time check but throw run-time errors. With the errors dumps the useful info which is needed.

DOUBLE QUERY INJECTIONS

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.

As these involve sub query injections, the focus is to use the internal query to dump the info we want and wrap around a query which is syntactically correct, passing the compile time checks and produces error at run time and in process spit the core query as part of error.

In MYSQL this is achieved by using combination of  count() and group by clause. In my personal understanding issue happens when the aggregate functions produce dynamic entries and group by clause clubs them and with the next round of aggregate function finds the values changed, causing duplicate entry issues. We discussed the same during the part 6. There the injection point was in GET parameter, and in this we used the POST parameter.

For detailed instructions, you can follow the video.

Basic query to cause injections :

Less-13 line number 57
@$sql="SELECT username, password FROM users WHERE username=('$uname') and password=('$passwd') LIMIT 0,1";
') or ('1')=('1 Will work nicely if injected in username and password field.   username = (' ') or ('1')=('1 ') AND password = ('  ') or ('1')=('1   ')
') or 1=1 --+ Will also work only in one field.   username = (' ') or 1=1 --+  ' commented out
') or 1=1 # will also work only in one field.       username = (' ') or 1=1 # ' commented out


Less-14 Line 57,58,59
$uname='"'.$uname.'"';
$passwd='"'.$passwd.'"'; 
@$sql="SELECT username, password FROM users WHERE username=$uname and password=$passwd LIMIT 0,1";

" or "1"="1 Will work nicely.   username = " " or "1"="1 " AND password = " " or "1"= "1 " 
" or 1=1 --+ Will also work.   username = " " or 1=1 --+  " commented out
" or 1=1 # will also work.       username = " " or 1=1 #  " commented out

SQLI-LABS SERIES PART-11

Thank you all your feedback's and the responses. I am highly motivated to complete this series and start with a new one soon after.

Today we will discuss about the injections in the forms. In the last 11 lessons of the series we discussed  injections via the GET request. When I had started to learn this topic, I realized that a lot of stuff was available on internet for the GET based injections but POST injections were rarely discussed. That increased curiosity in me much and this was the point when i started this lab. The forms , lesson 11 to 20 are different implementations similar to GET method. We would cover 

• Error based injections
• Double Query injections
• Boolean based Blind injections
• Time based Blind Injections
• Injections in update query
• Injections in the Headers
• Injections in cookies

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.

POST BASED INJECTIONS

In general, nothing changes with the change in injection point. The logic for injection remains the same, the process remains the same. In a general scenario we take up Less-11 and 12 for this. As the page displays a login field. therefore we can build our first sudo query which would be behind the scene as

SELECT * FROM table WHERE username="$uname" and password="$password".

The basic steps involved in the testing to exploitation are:

1. Fuzzing: Try to give random inputs to all points where it is accepted, be creative and send the values which the developer has failed to visualize. Objective is to try to break the underlying query and gain more insite on how the query is formulated by reviewing error.

2. Then try to fix the query by either providing the extra characters to balance off what we injected to break the query or comment off rest of query in such a way that it gets fixed.

3. Once we successfully achieved the above, we effectively get the left side, and right side of the injection and sql statement we inject in between these gets executed on backend.

As discussed in the previous post on error based injections, we used the UNION SELECT to dump the DB because the database layer was interacting with the web page and columns from table were visible on screen. same way we can see that a successful login leads to display of the username and password.

This can then be used to dump the database.

Less-11 line number 57
@$sql="SELECT username, password FROM users WHERE username='$uname' and password='$passwd' LIMIT 0,1";
' or '1'='1 Will work nicely if injected in username and password field.   username = ' ' or '1'='1 ' AND password = '  ' or '1'='1   '
' or 1=1 --+ Will also work only in one field.   username = ' ' or 1=1 --+  ' commented out
' or 1=1 # will also work only in one field.       username = ' ' or 1=1 # ' commented out


Less-12 Line 57,58,59
$uname='"'.$uname.'"';
$passwd='"'.$passwd.'"'; 
@$sql="SELECT username, password FROM users WHERE username=($uname) and password=($passwd) LIMIT 0,1";

") or ("1")=("1 Will work nicely.   username = (" ")or ("1")=("1 ") AND password = (" ")or ("1")=("1 ") 
") or 1=1 --+ Will also work.   username = (" ")or 1=1 --+  ") commented out
") or 1=1 # will also work.       username = (" ") or 1=1 #  ") commented out

EXCITED AND FIRING ALL GUNS

Thanks a ton to everyone,who is watching the series and also those who commented. A special thanks to Vivek Ramachandran for sharing link on Facebook and writing nice comments about it. Thanks a ton Vivek, it means a lot to me. I am motivated and excited to fire all guns. Never expected this kind of response

SQLI-LABS SERIES PART-10

In the last posts we discussed about different types of SQL injections: (Click the links to follow)

• Error based SQL Injections
• Double Query SQL Injections
• Boolean based Blind SQL Injections
• Time based Blind SQL Injections

Today we will take it further and discuss the use of outfile function or dumpfile function.

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.

USING THE OUTFILE/DUMPFILE

Well if the connection user which is configured to run the queries to the back-end DB has the privileges to write to file system (webroot of server or any other folder under it), then in that case, we can build queries and use the inbuilt function called outfile or dumpfile.

example query: select * from table into outfile "path-to-file/filename"

There are two functions which can be used in this case, outfile and dumpfile. With dumpfile, it dumps only one row without any formatting details. This is specially important if you are playing with binary data. The outfile preserves the formatting, carriage returns, etc and dumps multiple rows.

To practice this you can follow the Less-7 from the labs.

same way we can use mysql to read files from the file system. for that we can use the function called load_file(). By default we cannot execute system commands through mysql, but if mysql is misconfigured, then can lead to upload of User Defined Functions which can lead to a complete compromise of server.

example injection may look like:

' union select 1,load_file("/etc/passwd"),3 into dumpfile "/var/www/test.txt"

Less -7 Line number 31

$sql="SELECT * FROM users WHERE id=(('$id')) LIMIT 0,1";

1'))+or+1=1--+  -- Basic injection to detect sqli

SQLI-LABS SERIES PART 9

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.

TIME BASED INJECTIONS

In the previous post, we discussed the basics of Blind injections and started to explore Boolean based blind injections. In this blog post we would continue with the Blind injections and discuss TIME based injections. 

In certain web web applications, which are vulnerable but does not disclose errors, nor does the database display any fields on the web pages and neither does it react to physical boolean queries of yes and no meaning we cannot physically differentiate between true and false,

in that case, we can use time to distinguish between true and false. This can be achieved by using sleep() function. This function is non cpu intensive and if query is true will wait for some time before returning a response and respond quickly if false. This time difference in page reload gives us the correct characters one by one.

Another way to do time based injections is by use of heavy queries (benchmark queries) which are intensive and consume some CPU cycles if query returns true and are quick if it is false. It is always good to use sleep() function.

Less - 9  line number 29
$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";
1'+and+sleep(10)+--+  -- Basic injection to detect sqli
1'+and+if(1=1, sleep(10), null)+--+  -- Returns True  ( page load is approx 10 sec)
1'+and+if(1=0, sleep(10), null)+--+  -- Returns False (page load is almost instant)


Less-10 line number 28,29

$id = '"'.$id.'"';
$sql="SELECT * FROM users WHERE id=$id LIMIT 0,1";
1"+and+sleep(10)+--+  -- Basic injection to detect sqli
1"+and+if(1=1, sleep(10), null)+--+  -- Returns True  ( page load is approx 10 sec)
1"+and+if(1=0, sleep(10), null)+--+  -- Returns False (page load is almost instant)


Hope this makes some sense, after all I am a dhakkan.

SQLI-LABS SERIES PART-8

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.

BLIND INJECTIONS

Continuing the SQLI-LABS series, we discussed the Error based injections, and discussed Union type injections and double query injections. In today's post we would be discussing Blind injections. Blind injections got this name because during blind injections, you do not get any help from the application. All the errors are suppressed from the end user.
Therefore complete injection is based on a guess. The tester does not see any error responses to tune his  injections.
Blind Injections can be classified mainly into two categories:

• Boolean based Blind injections
• Time based Blind injections.

Boolean Based

As per wikipedia "In computer science, the Boolean or logical data type is a data type, having two values (usually denoted true and false), intended to represent the truth values of logic and Boolean algebra. It is named after George Boole, who first defined an algebraic system of logic in the mid 19th century".

Well in certain web applications, you can witness that the database does not write any fields on the web page or somehow union injections do not work, and the mysql errors are also not displayed on the page, so technically there is no direct channel through which the database writes on web page. In this case the only option left is to use blind injections. With Blind injections we cannot dump the strings or names directly but need to deduce names character by character.

In general when we were dealing with error based injections, we ask the database questions like, dump us the database name, version, table names etc. In case of blind injections, we change the way we ask questions to database and rephrase questions like is the first letter of the database this? and answer comes out as either yes or no or true or false. Check the video at the end of the post for more detailed explanation.

Less-8 line number 29
$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";

basic injection example:
1' AND '1'='1 -- returns true

1' AND '1'='0  -- returns false

Therefore by evaluating the strings character by character we can dump the complete database.

SQLI-LABS SERIES PART 6,7

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned. 

DOUBLE QUERY INJECTIONS OR SUBQUERY INJECTIONS.

In the last 5 parts of the series we learnt about some basics about the error based injections and used the UNION statements to dump the database using the web application. Well we could achieve it because the database was interacting with web page and some database fields were visible on the web pages. A basic injection looked like id=-1 union all select 1,2,3 --+ and we were able to see the username name and password field displaying value 2 and 3. For detailed explanation watch video's 2 to 5.

In a scenario when the database does not directly display columns on the wep page, then the above technique cannot be used. To understand this better you can check Lesson 5 or 6 of the sqli-labs series. 

As we see we just see a generic message "You are in".  Therefore in this case, the database is not displaying any files on the page. In this case only way the database is displaying into is through the mysql error. (note: I am interchangeably using the Lesson 5 and 6, only thing different is way to produce error)

So primary objective in a double query injection is to create a query injection in such a way which is syntactically correct (correct at compile time) but produce an error at run time thereby spitting useful information in the errors. In case of MSSQL server cast errors dumps the info but in case of MYSQL, being flexible returns empty rows. Therefore some genius researchers found a combination of use of aggregate functions, group by clause, and use of random functions to produce errors are run time due to dynamic calculations involved in random function and aggregate function like count. 

Hope this makes some sence, after all I am a dhakkan. 

Less-5 line number 29

$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";

• ' or '1'='1 Will work nicely.   id = ' ' or '1'='1 ' LIMIT 0,1
• ' or 1=1 --+ Will also work.   id = ' ' or 1=1 --+  ' commented out
• ' or 1=1 # will also work.   id = ' ' or 1=1 # ' commented out

Less-6 line number 28,29

$id = '"'.$id.'"';

$sql="SELECT * FROM users WHERE id=$id LIMIT 0,1";

• " or "1"="1 Will work nicely.   id = " " or "1"="1 " LIMIT 0,1
• " or 1=1 --+ Will also work.   id =  " " or 1=1 --+ " commented out
• " or 1=1 # will also work.       id = " " or 1=1 # " commented out

SQLI-LABS SERIES PART - 2,3,4,5

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned. 

In the first part of the series we downloaded the PHP code files and installed them on the backtrack machine or under XAMPP on windows.

In today's lesson We would start with the Error based SQL injections. 

What exactly is SQL injection?

SQL injection is a technique often used to attack databases through a website. SQL injection is a code injection technique that exploits a security vulnerability in a website's software. -- source wikipedia

How does SQL injection happen?

Let us take the example of Less-1, the webpage is taking an input through the parameter "ID" and passes it on to the backend database by constructing a query in real time.

ERROR BASED SQL INJECTION

Error Based Sql injection is called so because in this errors are being displaded on the web page, and these errors are used to discover the underlying query.

Less-1 
if you open the source of the index.php under Less-1, you would see on line 29
$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";
in here we see that the variable $id is being wrapped around single quotes.
id = ' $id ' , Now when a  tester provides a  ' or 1=1 then it becomes id = ' ' or 1=1  '  thereby effectively evaluating the complete query as id= empty string  or (evaluate one equals one) and escaping the data boundary and getting executed as code. As there is a quote on right side which we either need to handle or comment out remaining part of query.

• ' or '1'='1 Will work nicely.   id = ' ' or '1'='1 ' LIMIT 0,1
• ' or 1=1 --+ Will also work.   id = ' ' or 1=1 --+  ' commented out
• ' or 1=1 # will also work.       id = ' ' or 1=1 # ' commented out

Less-2 line number 31,32

$sql="SELECT * FROM users WHERE id=$id LIMIT 0,1";

• or 1=1  Will work nicely.   id =   or 1=1  LIMIT 0,1
• or 1=1 --+ Will also work. id =   or 1=1 --+ 
• or 1=1 # Will also work.    id =   or 1=1 #

Less-3 line number 31

$sql="SELECT * FROM users WHERE id=('$id') LIMIT 0,1";

• ' ) or ('1')=('1 Will work nicely.   id = (' ') or '1'=('1 ') LIMIT 0,1
• ' ) or 1=1 --+ Will also work.   id = (' ') or 1=1 --+  ') commented out
• ' ) or 1=1 # will also work.       id = (' ') or 1=1 # ') commented out

Less-4 line number 28,29

$id = '"' . $id . '"';
$sql="SELECT * FROM users WHERE id=($id) LIMIT 0,1";

• ") or ("1")=("1 Will work nicely.   id = (" ")or ("1")=("1 ") LIMIT 0,1
• ") or 1=1 --+ Will also work.   id = (" ")or 1=1 --+  ") commented out
• ") or 1=1 # will also work.       id = (" ") or 1=1 #  ") commented out

hope you all like it.

SQLI-LABS SERIES PART-1

Issue with me is that I have a very unconventional way of self learning and unless the core concepts are clear, things fall logically in place and I have answer to all how and why questions in my head,  cannot accept and retain those thopics.

Well for me my good friend Alper has always been there whenever stupid ideas pop'ed into my head and I  needed someone to share, discuss and to show me the right path. Pranab has always supported me in the odd hours of research and learning, when we are trying to understand things....

Shashank another good friend of mine pushed me to share my ideas and know how with others.... so revival of my blog is because of him. Not to forget my buddy Neeraj who was with me in all the ups and downs of my life....(Miss you uncle.................)

Thank a ton to all my friends. It is only because of them that I am what I am today.

SQLI-LABS SERIES

So here I am sharing the little I know....
Plans are big. If audience likes the stuff, then I will invest more time to share and bring forward more subjects.....

I started with SQL Injections...... why SQL injections. Well there is a lot talked about on this subject on internet from basic to advanced stuff but no single resource explains the logic behind the scene for all types in 1 place , how it works and why it works and most are like do this then this and then this but why it needs to be done like that is not explained...........

SQLI-LABS is my attempt to explain the basics involved in SQL injections. I tried to be a DHAKKAN during my explainations.... Hope you all like them.

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned. 

SQLI-LABS is a test bed of various lessons to explain and learn different types of SQL injections.

1. Error Based Sql Injections - Union select type.
2. Error Based Sql Injections - Double Query type.
3. Boolian Based Blind Injections.
4. Time Based Blind Injections.
5. Dumping the DB using outfile / Dumpfile.
6. POST based Sql injections Error based type - union select.
7. POST based Sql injections - Double injection type.
8. POST based Blind injections -Boolian / Time based.
9. Injection in the UPDATE query.
10. Injection in the Headers.
11. Injection in cookies.

Download the test bed from https://github.com/Audi-1/sqli-labs

Installation video can be found at http://www.youtube.com/watch?v=NJ9AA1_t1Ic

Rediscovering myself

Hi All,

well over past few years, i had lost myself in the crowd.....

and had just become a machine, but thanks to my good friend, Shashank Dixit who pushed me to rediscover myself. 

Rejuvenated with the newly gained energy, and backing by a lot of good friends. Special thanks to  Alper Celik, Pranab Kumar, Shashank dixit, Krishna Kumar and many more... I am back with a promise to myself that I will try to  help others in the field of infosec as much as i can.....Even more than ever before...