Jump to content

Recommended Posts

any value you dynamically put into an sql query statement can be anything and could be used to inject sql.

 

if you are using the value from your radio/checkbox, such as an 'on' value or an id..., in an sql query statement, it can be anything that a bot/hacker chooses to submit and could contain sql.

 

if on the other hand, all you are doing is testing if a radio/checkbox is set and using that logic condition to cause your code to use a value in an sql query statement that is solely dependent on your code for that value, then no, submitted sql cannot be injected in this way.

 

also, escaping string data will only protect against sql injection in values that are used as strings in the sql query statement, i.e. enclosed by single-quotes within the sql statement. values that are used as numerical data in the sql query statement need to be validated that they are only of the expected numerical type, since sql can be injected that contains no characters that the string escape function will protect against.

 

of course, the problem of sql injection goes away if you use prepared sql queries, where the data values are bound to place-holders in the sql query statement. in this case, your code is only concerned with application level validation, i.e. telling the user if something he submitted cannot/won't be used since it was empty, not of an expected value or format...

Edited by mac_gyver

How your HTML form looks like is completely irrelevant for the communication between the client and the server. Anybody can send any data to you.

 

It's important to understand that the client and the server are actually just exchanging HTTP messages. All the browsers and HTML documents and fancy GUIs are only there to make the WWW human-friendly. We don't need them. I could open my console right now, create an arbitrary HTTP message and send it to your server. If you then blindly accept the data based on the assumption that I've used your form, that's a problem.

 

Any client-side restrictions you may have set up are purely advisory. It's simply a way of telling the user which kind of data you expect from them. The actual data you get may be completely different.

 

So, yes, you have to escape all input, be it a POST parameter, a cookie, an HTTP header or whatever. Even better: escape every value and don't make any assumptions about whether or not a certain value is dangerous. It's too easy to get this wrong. For example, many people still believe that $_SERVER['PHP_SELF'] is just a harmless filepath which couldn't possibly cause any harm. Well, this is wrongAnd even if a value is indeed not dangerous, it can still contain critical characters and cause a syntax error.

This thread is more than a year old. Please don't revive it unless you have something important to add.

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.   Restore formatting

  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...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.