Table of Contents for
Python Web Penetration Testing Cookbook

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Python Web Penetration Testing Cookbook by Dave Mound Published by Packt Publishing, 2015
  1. Cover
  2. Table of Contents
  3. Python Web Penetration Testing Cookbook
  4. Python Web Penetration Testing Cookbook
  5. Credits
  6. About the Authors
  7. About the Reviewers
  8. www.PacktPub.com
  9. Disclamer
  10. Preface
  11. What you need for this book
  12. Who this book is for
  13. Sections
  14. Conventions
  15. Reader feedback
  16. Customer support
  17. 1. Gathering Open Source Intelligence
  18. Gathering information using the Shodan API
  19. Scripting a Google+ API search
  20. Downloading profile pictures using the Google+ API
  21. Harvesting additional results from the Google+ API using pagination
  22. Getting screenshots of websites with QtWebKit
  23. Screenshots based on a port list
  24. Spidering websites
  25. 2. Enumeration
  26. Performing a ping sweep with Scapy
  27. Scanning with Scapy
  28. Checking username validity
  29. Brute forcing usernames
  30. Enumerating files
  31. Brute forcing passwords
  32. Generating e-mail addresses from names
  33. Finding e-mail addresses from web pages
  34. Finding comments in source code
  35. 3. Vulnerability Identification
  36. Automated URL-based Directory Traversal
  37. Automated URL-based Cross-site scripting
  38. Automated parameter-based Cross-site scripting
  39. Automated fuzzing
  40. jQuery checking
  41. Header-based Cross-site scripting
  42. Shellshock checking
  43. 4. SQL Injection
  44. Checking jitter
  45. Identifying URL-based SQLi
  46. Exploiting Boolean SQLi
  47. Exploiting Blind SQL Injection
  48. Encoding payloads
  49. 5. Web Header Manipulation
  50. Testing HTTP methods
  51. Fingerprinting servers through HTTP headers
  52. Testing for insecure headers
  53. Brute forcing login through the Authorization header
  54. Testing for clickjacking vulnerabilities
  55. Identifying alternative sites by spoofing user agents
  56. Testing for insecure cookie flags
  57. Session fixation through a cookie injection
  58. 6. Image Analysis and Manipulation
  59. Hiding a message using LSB steganography
  60. Extracting messages hidden in LSB
  61. Hiding text in images
  62. Extracting text from images
  63. Enabling command and control using steganography
  64. 7. Encryption and Encoding
  65. Generating an MD5 hash
  66. Generating an SHA 1/128/256 hash
  67. Implementing SHA and MD5 hashes together
  68. Implementing SHA in a real-world scenario
  69. Generating a Bcrypt hash
  70. Cracking an MD5 hash
  71. Encoding with Base64
  72. Encoding with ROT13
  73. Cracking a substitution cipher
  74. Cracking the Atbash cipher
  75. Attacking one-time pad reuse
  76. Predicting a linear congruential generator
  77. Identifying hashes
  78. 8. Payloads and Shells
  79. Extracting data through HTTP requests
  80. Creating an HTTP C2
  81. Creating an FTP C2
  82. Creating an Twitter C2
  83. Creating a simple Netcat shell
  84. 9. Reporting
  85. Converting Nmap XML to CSV
  86. Extracting links from a URL to Maltego
  87. Extracting e-mails to Maltego
  88. Parsing Sslscan into CSV
  89. Generating graphs using plot.ly
  90. Index

Identifying URL-based SQLi

So, we've looked at fuzzing before for XSS and error messages. This time, we're doing something similar but with SQL Injection, instead. The crux of any SQLi starts with a single quotation mark, tick, or apostrophe, depending on your personal choice of word. We throw a tick into the URL targeted and check the response to see what version of SQL is running if successful.

We will create a script that sends the basic SQL Injection string to our targeted URL, record the output, and compare to known phrases in error messages to identify the underlying system.

How to do it…

The script we will be using is as follows:

import requests

url = “http://127.0.0.1/SQL/sqli-labs-master/Less-1/index.php?id=”
initial = “'”
print “Testing “+ url
first = requests.post(url+initial)

if “mysql” in first.text.lower(): 
  print “Injectable MySQL detected”
elif “native client” in first.text.lower():
  print “Injectable MSSQL detected”
elif “syntax error” in first.text.lower():
  print “Injectable PostGRES detected”
elif “ORA” in first.text.lower():
  print “Injectable Oracle detected”
else:
  print “Not Injectable J J”

The following is an example of the output produced when using this script:

Testing http://127.0.0.1/SQL/sqli-labs-master/Less-1/index.php?id=
Injectable MySQL detected

How it works…

We import our libraries and set our URL manually. We can set it as a sys.argv variable if needs be; however, I have hardcoded it here to show the expected format. We set the initial injection string as a single quotation mark and print that the test is starting:

url = “http://127.0.0.1/SQL/sqli-labs-master/Less-1/index.php?id=”
initial = “'”
print “Testing “+ url

We make our first request as our provided URL and the apostrophe:

first = requests.post(url+initial)

The next few lines are our detection methods to identify what the underlying database is. The MySQL standard error is:

You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the
right syntax to use near '\'' at line 1

Correspondingly, our detection attempt reads in the text of response and searches for the MySQL string and, if so, prints out that the attempt was successful:

if “mysql” in first.text.lower(): 
  print “Injectable MySQL detected”

For MS SQL, an example error message is:

Microsoft SQL Native Client error '80040e14'
Unclosed quotation mark after the character string

Since there are multiple potential error messages, we need to identify one constant that occurs across as many of them as possible. For this, I have chosen native client, though Microsoft SQL could also be used:

elif “native client” in first.text.lower():
  print “Injectable MSSQL detected”

The standard error message for PostgreSQL is:

Query failed: ERROR: syntax error at or near
“'” at character 56 in /www/site/test.php on line 121.

Interestingly, for what is always a syntax error in SQL, the only solution that regularly uses the syntax word is PostGRES, which allows us to use that as the distinguishing word:

elif “syntax error” in first.text.lower():
  print “Injectable PostGRES detected”

The last system we check is Oracle. An example error message for Oracle is:

ORA-00933: SQL command not properly ended

ORA is the prefix for the majority of Oracle errors and therefore can be used as the identifier here. There are only a few fringe cases where a non-ORA error message would apply to a trailing tick:

elif “ORA” in first.text.lower():
  print “Injectable Oracle detected”

In the event in which none of these apply, we have a final else statement that declares the parameter is not injectable and that an error was made in picking this parameter.

An example output is shown in the following screenshot:

How it works…

There's more…

Tying this script in with the spider found in Chapter 1, Gathering Open Source Intelligence, would make for a quick efficient way of identifying injectable URLs across a web page. A method of identifying parameters to inject would be necessary, which can be achieved through simple regex manipulation in most cases.

A set of useful SQLi test pages were made by Audi-1 and can be found at https://github.com/Audi-1/sqli-labs.