point of performing SQL injection. One of the first times I tried to understand SQL injection
was when I was trying to learn programming on my own and stumbled across some SQL
injection examples on the internet and the topic really started to interest me. SQL injection
should have been something easy to learn considering the the vx zines from 29A that I was
reading at the current time, mentioned that if you had trouble learning assembly
programming then you should consider learning some form of server side scripting instead.
So I guess at that time it got me into the idea of reading some perl and eventually some PHP,
which got me on to the topic of SQL injection some how. When I asked my extra math class
teacher at the time, who was a computer science major to explain SQL injection to me, he
had no idea what it was and instead explained linked lists to me and how to do a binary
search. This confused the crap out of me so I was still stuck trying to learn assembly
programming so I could understand how malware worked. This added an extra item to my
mental curiosity list which I would eventually figure out much later :SQL injection. I'm sure
this blogpost will raise my position on some kind of interesting hidden NSA list, but please
take in mind that my motivation for writing this blogpost is purely to share my experience of
learning something that took me ages to wrap my mind around. SQL injection is really not
such a complex topic, if somebody explains it to you like you are five. There are very few
tutorials on the internet that happen to do just that. So this is my attempt at explaining
some things around SQL injection to five year olds. In the least this article should have you
understand some basics around SQL injection and should get you one step closer to learning it.
Before we get into how to learn SQL injection, let's discuss what SQL injection really is. If
you would like to learn something you should really start with what you already know and
build on that. If you would just like to hack random people dump their databases from their
vulnerable custom crappy PHP sites, then I would recommend that you download sqlmap and
google for some youtube videos on sqlmap. I hope that this is not the path you choose to
take.
SQL injection is the ability to run your own SQL on someone else's server or within someone
else's web application. Before we get into the details of what the implications of running
your SQL on my box could be, lets just have a brief history lesson on web application
architectures:
In the past people generally ran a dedicated server with for example PHP,Apache, MySQL and
whatever else all on one server. That means that if the web application was vulnerable and
you could somehow gain access to the server from MySQL then ,given a few attacker
favorable conditions, you could possibly get a shell and go as far as rooting the server
completely. People use to run things in chroot's as a precaution for this very reason, don't
get me started on chroot's though, its very sad to see that many modern sysadmin are
familiar with things like Docker, but not with the basics of using a chroot. In modern times
the "cloud" is very popular and so is decoupling your web application. These days you could
be hacking a web application that is running on a server where the server connects to a
managed MySQL run by the Cloud provider. Your server would probably only be running PHP
and Apache with your code running on the server. You might be using managed cloud
loadbalancers that sit in front of your web application. This type of decoupled architecture
brings many new challenges to the modern penetration tester. In my opinion the
penetration testing occupation will disappear in our life time(not completely, it will just
cease to exist as we know it) due to the advent of bug bounty sites and also due to the
increased use of the "Cloud". There is another trend I won't discuss, but I'll just mention it
briefly: the modern "serverless" architecture of web applications. This is kind of a stupid
term if you think about it, because the resources are running on a server, whether you are
running the server or not. "Serverless" web applications also introduce a very interesting and
unique challenge for modern penetration testers. I suspect in the next two years we will see
some very interesting research from the infosec community regarding this topic.
Something to take note of is that the reason why you get different types of SQL injection has
to do with two things mainly:(I'm happy to hear if you care to differ, this is just an opinion
piece based on my experience and limited understanding. If you disagree then leave me a
comment or see if you can get hold of me somehow and send me a mail. I'm a nice guy! I'm
happy to hear you out. )
1. There are different ways of getting the output of the SQL that you are possibly running on
the other person's application's database. For example you
can get feedback by ex filtrating data via DNS , by getting errors printed to the frontend of
the web application and there are more ways, but I'll cover
all of those that I could think of later in this article.
2. Depending on the statement type used in query you are injecting to and where in the
query you are injecting to would determine what type of SQL injection technique you are
making use of. For example you could be injecting into a part of a query that is trying to
evaluate something to either true or false in this case you could not do much but check for
things and check if those things are true or false. What I meant by injecting into different
statement types for example you could be injecting into an INSERT query or for example the
most common would be to inject into a SELECT query. This topic is covered much better in
The Web Application Hacker's Handbook so I would recommend reading it, see the chapter
about "Injecting Into SQL".
There are a few topics that are very important to understand when it comes to SQL
injection:
1. How to get feedback on the SQL queries that you are running on someone else's resources.
In other words how to get the output of the queries that you are running on someone else's
SQL server. (That is if your queries are actually running.)
2. Possible "bad" things that you could do once you are able to run your own SQL code on
someone else's SQL server. Just to be clear when I say SQL server I am referring to any kind
of SQL server (MySQL, Mariadb, Postgresql, Sqlite, Microsoft SQL server or any other
relational database technology for that matter), I am not only referring to MS SQL server as
many people like to refer to when they use the term "SQL server".
3. Different permissions models and security features of different databases.
4. Get to know different types of SQL injection and how each type works.
5. General SQL is very handy in this regard.
When you are new to hacking web applications there is something that nobody explains to
you.
SQL injection and even XSS can be exploited via POST. Yes this might seem obvious to you,
but this wasn't obvious to me
when I first started. I had no idea that sql injection could be exploited in a way that did not
require a browser.
You will be much closer to hacking web applications or even mobile applications,
once you realize that there are multiple ways to interact with web applications other than
the conventional Chrome,Firefox,IE,Opera or Chromium.
This really took me a while to grasp. All the examples I saw on the internet were doing
things like interacting with the web application via GET
in the URL bar.
There are a few things that you can do with SQL injection, and this is a topics that created
a great deal of confusion for me from the start. What you are able to do is very much
determined by the
query you are injecting to and the application logic:
1. In some cases you can use sql injection to bypass authentication of an application. This is
in some cases.
This is not in all cases of SQL injection. This took me a while to figure out. I always just saw
people do things
like add ' or 1=1 -- into queries that checked a user and password against the database.
2. You can use sql injection to extract data out of some tables or a whole database, this is
not possible
in all cases of sql injection and your ability to exfiltrate data is really limited
to different mechanisms that you can use to exfiltrate the data. A good database
administrator will lock that database
down to the point where even if SQL injection exists in an application the attacker would
either have trouble getting data out ,it will be impossible
to exfiltrate data or it will be very slow to get the data out.
What are some resources that I can use to learn about SQL injection?
1. Audi1 on youtube's SQL injection tutorials. Here is a link to the
I
cannot emphasize enough just how good these videos are at explaining SQL injection.
2. Play around with sqlmap and Damn Vulnerable Web App.
3. Read: The Web Application Hacker's Handbook
4. Read the OWASP Testing Guide.
What are some resources that I can use to learn more about the blue team side of SQL
injection? Wow I'm glad you asked! Some people are only interested in being little brats that
want to destroy things, but have no interest in the defensive side of infosec, don't be that
guy please. The really good "bad guys" are usually very knowledgeable in both sides of the
infosec coin.
1. The Database Hacker's Handbook. This is an excellent book if you would like to learn each
database technology in depth, how to defend each technology, but also more on how to
exploit each database. The book covers: MySQL, Postgresql, MSSQL, and Oracle.
2. Hack Proofing MySQL
see: https://web.archive.org/web/20060323123411/http://www.ngssoftware.com/papers/ HackproofingMySQL.pdf
Let's have a look at different types of SQL injection:
1. The first type that most people know is error based SQL injection. What is error based SQL
injection? Error based SQL injection is very uncommon these days, but it is not impossible to
encounter it in the modern day world. Error based sql injection is where you see some kind
of error output from the web application when you input a specific input into the web
application that somehow breaks the query string. What does this actually mean though?
Let's look at an actual example by one of my favourite hackers
bitquark: https://hackerone.com/reports/20279
Just take note that being able to get a web application to throw errors upon adding a single
quote into a get parameter doesn't mean the application is vulnerable to SQL injection,
although it could possibly be vulnerable, you will have to do some further testing to verify
this. I once had a bit of an embarassing moment when I found an error based on the behavior
I just described on vk.com only to find out later that the error was an error from a
component that they used from mediawiki and that this was a known behavior in the
mediawiki software. I was busy participating in their bugbounty and I guess I got excited a
bit too early. Here is a screenshot of the error that I got.
2. Time based SQL Injection:
This is what is often referred to as one of the types of blind sql injection. Why is it called
blind sql injection, well you can't see anything obvious happening in the frontend of the web
application when you find a valid injection point. So you start poking around in the dark.
Time based sql injection is a weird type of SQL injection where you get feedback from the
database by running a
query that does something to timeout or delay the database. This works by running a valid
query by injecting SQL
and making use of a built in function that is usually used to timeout or benchmark a query.
This doesn't make that much sense if somebody just
explains it without examples. So let me show an example so it makes more sense. (My
examples won't be nearly as good as the videos by audi1 that I linked
earlier so please check them out. )
My example I will be running a sqlite query that just generates something random, but you
can think of it as a function
that times out the query since it takes so long to execute the query which is generating the
random blob. I'm using sqlite in my example
, for a few reasons but the main reason is, because it is easy to install and work with.
The first thing to run is:
So now let's try run it with the time command in front of it, its the unix command for
determining how long it
will take to run a command:
(This command will create a file test.db , feel free to delete it afterwards)
So how does running this tie in with time based sql injection. Well let's consider a valid
query with no benchmarking and now for a moment consider that you can't see this query
run in the background of the web application. How would you know if you injected into the
query? You can't see anything in the frontend of the web application so there is no
immediate feedback.
Something interesting to note is that not all databases have these types of built in SQL
functions. One example of such a database is Apache Derby. (Or I am under the impression
this is the case)
I once found an application that was vulnerable to SQL injection , but made use of Apache
Derby on the backend and from what I could find on the internet
Apache Derby database did not have any built in functions that could be used to benchmark
or timeout the query. Perhaps there are other built in functions that
I could have used to get feedback. I reckon it would be interested to see the comments if I
post this article on reddit to see if anyone thinks otherwise.
3. Boolean based SQL injection:
For some time I thought I was the only one who found boolean based SQL injection rather
confusing, as part of writing this post I ended up googling the topic and found that this was a
topic of great confusion for many other people too. Here is an example of a
security.stackexchange post where someone expressed their confusion
Something that nobody explains to you in depth when you start out with SQL injection is that
occasionally you will find a boolean based SQL injection that can be used to bypass
authentication in an application. It took my ages to understand this as I really couldn't get
why examples that I saw on the internet showing how to bypass authentication using SQL
injection tied in with the idea of stealing data out of the database with this same "SQL
injection" thing. Stealing data and bypassing authentication were really two different things
to me so I didn't understand how SQL injection could be used to do both. Obviously if you
could bypass authentication then you would have access to more parts of the application as
opposed to an unauthenticated session of the web application, but I still didn't understand
how the same attack could be used to steal data. I''ll continue in post two of this series of blogposts.
