1

I scanned one of my test sites with Acunetix, and it shows that it has some SQL injection vulnerabilities due to an unclosed quotation mark.

If I enter 1'" in the form, I get back the error message.

And if I enter

"...MessageHandler.asmx/ChangePassword?PIN=1%27"&CurrentPwd=1&newPwd=1"

in the URL, I get the error message.

My question is, where do I go from here to poke around some more? I've read tutorials on injections, but I just can't seem to figure out what to do from this point. I know I have an injection vulnerability, but what now?

What would my next steps be to see what kinds of other data I can see?

jww
  • 97,681
  • 90
  • 411
  • 885
  • Are you concerned with exploiting the attack vector or fixing it? – h0r53 Jan 31 '17 at 16:48
  • https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) – Reginaldo Rigo Jan 31 '17 at 16:51
  • In what programming language is this test site written? – Dan Bracuk Jan 31 '17 at 17:26
  • As pointed out in a comment below prepared statements can also be used and may be easier for you to implement on an existing site. Both methods are not 100% defense, particularly if the SQL is constructed dynamically based on user input. But if input is limited to parameters then stored procs are very secure. There is a good explanation of how prepared statements are used to avoid SQL injection here http://stackoverflow.com/questions/1582161/how-does-a-preparedstatement-avoid-or-prevent-sql-injection. I suggest you read that post as well. – E LaRoche Jan 31 '17 at 18:42
  • At this point, I'm not interested in fixing it on my side. I need to actually show the people in charge how bad this is and that they need to understand and fix it. I'm not a programmer. Showing them that there's sections of the website that can accept SQL commands doesn't actually "show" them much from their point of view. I could send them things to read, but ultimately I'd like to show them something visual that is clearly bad that I shouldn't be able to do. Once they see that, then they'd be more inclined to either take it offline or spend time to fix it. –  Jan 31 '17 at 20:41
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) or [Database Administrators Stack Exchange](http://dba.stackexchange.com/) would be a better place to ask. DBAdmins may be able to suggest some automated tests. – jww Aug 30 '18 at 01:14
  • Please don't make more work for people by vandalizing your posts. By posting on the Stack Exchange (SE) network, you've granted a non-revocable right, under the [CC BY-SA 3.0 license](//creativecommons.org/licenses/by-sa/3.0), for SE to distribute that content (i.e. regardless of your future choices). By SE policy, the non-vandalized version of the post is the one which is distributed. Thus, any vandalism will be reverted. – Makyen Aug 30 '18 at 01:25

1 Answers1

0

In Microsoft SQL Server, SQL Injection is negated by using stored procedures. It will not execute commands sent in, even as parameters. If you replace embedded SQL with stored procedures you will eliminate the SQL injection threat. Is still good practice to sanitize your input thru GUI validation routines, but these can be easily by passed by an experienced hacker so its important to also eliminate embedded SQL.

E LaRoche
  • 1,106
  • 1
  • 7
  • 8
  • Stored procedures are not the only means by which one can mitigate injection attacks, nor is the use of stored procedures a guarantee that one is immune to such attacks. You can use embedded SQL by way of Prepared Statements and be better protected from injection attacks without the use of stored procedures. – alroc Jan 31 '17 at 18:11