Here’s a reflection: What would motivate the “correction” of the SQL Injection based on such ineffective measures? No easy answer. Character limits, types of characters and “escaping” double quotes are just the most common cases. After some trial and error, I came to the following conclusion: The application removed the commas passed in the vulnerable parameter.Ī brief explanation… For years, here at Tempest we have seen several cases of exploitation of SQL Injection with restrictions. However, for some reason – until then – unknown, I was unable to execute some payloads. Very well during a pentest job at Tempest, I came across a Blind SQL Injection and, after proving the concept that it was possible to run SQL on the server, I decided to extract some information from the database to proceed with other attacks (I wanted to extract password hashes from the database). Note: The substring functions use the comma to separate the received parameters. When you want to explore a Blind SQL Injection, you will normally use a substring function in order to make the comparison, character-by-character, of the information that you want to extract from the database. Therefore, if you are not familiar with SQL Injection ( ), I recommend that you read a little more about it beforehand. This blogpost is about how to efficiently exploit a Blind SQL Injection when the vulnerable application removes the character “,” (comma) from the request.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |