I'm testing my own web page with the following vulnerabilities.


Form escapes ' to \'

So if a user tries to enter the following information:

username: 'or'1=1

password: m

username will actually look like \'or\'1=1


Script tags allowed.

So if a user tries to enter:

username: <script>alert(0)</script>

password: m

then a dialog box will pop up with 0.

I'm wondering whether the first method is truly secure against sqli. I know there are things about handling comments, but is this a good way to handle the single quote?

Also, in the second vulnerability, what can a malicious user do in this case? I'm aware of XSS attacks, but I thought those were with the URL. Is this really a big security flaw?


3 Answers 3


Both cases are serious vulnerabilities, and the security approach is wrong.

First of all, the form itself shouldn't escape anything. You might want to check the input, but you do not manipulate it. Escaping is done in a specific context like a database query, not globally.

No, it's not secure to simply prepend a backslash to single quotes in the application:

  • Database systems support different character encodings which may or may not match the encoding used by your application. If they don't match, the escaping attempt is essentially a shot in the dark and may not work at all. There's a famous injection attack which exploits the differences between two common character encodings. The only way to be sure is to use an encoding-aware library function of your database system. For example, MySQL has mysql_real_escape_string().
  • Backslash-escaping is a nonstandard mechanism which only works in some special modes of some database systems (like MySQL). If the server configuration or the underlying database change, you may again lose all protection.
  • There are much more characters that you need to take care of. This also depends on the database system and its configuration.

Manual SQL-escaping is actually a rather poor approach, because it's complicated, tedious and error-prone (as you can see). A more modern solution is to use prepared statements and not stuff any user data into SQL queries in the first place. If, for some reason, prepared statements are not an option, make sure to use the right library function instead of trying to invent your own solution.

Your second case is a full-blown cross-site scripting vulnerability, so an attacker can do anything which is possible with XSS (like stealing a session cookie). No, XSS is not limited to URLs in any way. You've just proved that yourself. An XSS attack happens when a user is able to inject data into an HTML context. Where that data comes from is irrelevant; could be the URL, could be a form paramater, could be a cookie, an HTTP header, a database string, anything.

  • Thank you for your response. I'm confused with the second case because I've always seen XSS as sending someone a URL that has the script embedded in it (i.e. www.mysite.com/hello.php?q=<script>alert(0)</script>). If the URL isn't affected by form input, then how can you perform this attack?
    – Chelsea
    Commented Mar 20, 2015 at 4:08
  • Well, the attack has just happened: You've put a script tag into the form input, and the browser has executed it. An attacker could, for example, set up a pre-filled form on another site and use your site as the target. If the victim visits the other site and submits the form (which can happen automatically through JavaScript), the form payload will be executed in the context of the victim's browser. So it's just as dangerous as a URL-based attack. Of course this attack is a bit more difficult than setting up a simple link, but that doesn't mean it won't happen.
    – Fleche
    Commented Mar 20, 2015 at 4:19

OWASP offers some solid advice on their site: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet You'll be safer and better off using a well-respected resource than inventing your own solution through trial and error.

However, learning how an attacker works through experimentation like you're doing, is one of the best ways of learning how it all works, and why it's so important. This will make you a better developer.

  • I respect you taking the time to post a response, but this does not answer my question. I am aware of these methods already, but I am looking at above vulnerabilites specifically.
    – Chelsea
    Commented Mar 20, 2015 at 2:07
  • OWASP's page answers your question about escaping the apostrophe. Go down to owasp.org/index.php/… Commented Mar 20, 2015 at 2:19
  • I'm not trying to defend against this, I'm curious about what an adversary can do to exploit this (in both cases). Sorry if that wasn't clear from the get-go.
    – Chelsea
    Commented Mar 20, 2015 at 3:01
  • Ah. There are entire classes of attacks based on running arbitrary SQL. The attacker could insert x' or 1=1 in the password field, hoping the resultant SQL would look like select auth_level from users where password='x' or 1=1 There are ways of structuring queries to discover table schema, user lists, or even the classic Robert';drop table students (Little Bobby Tables, as his mom calls him.) Commented Mar 20, 2015 at 4:31

if you're still confused by the second example and want to think of a non-URL attack then imagine a website user is asked for secondary authentication but is already authenticated (as in a bank website when you are often asked to enter your password again to authorised a transfer). The person asks for an action to complete (like the bank transfer example) and doesn't notice that the action hasn't yet completed but they are taken to the authentication page with your login form for the secondary auth. They walk away from their desk because they mistakenly think that everything is now complete (lots of people don't ever log off themselves which is a problem!) A passing attacker comes up to their screen and enters a script into the login box that returns the session cookie, writes the session down (or just uses the email client to email it to themselves) and disappears to a nearby computer and uses that cookie to start using the website themselves.

Nasty one! One of a hundred examples I'm sure you can think of without URLs being involved (think of someone asking a user to type something into their login box "as a test of your security sir, I'd just like you to type in blah blah".. and so it goes on!

Also, remember that many systems will audit username and password entries (the latter in an encrypted form I hope!) in log files and databases so with this vulnerability an arbitrary user can inject script code into your database or log file and a technical user with clients that are not necessarily free from injection or XSS flaws could read that data and trigger an attack on their system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .