eldan88 Posted June 24, 2014 Share Posted June 24, 2014 Hey Guys. I have a quick question. Should i "prep" input values coming from a radio or checkbox input field? Can an SQL injection occur through those 2 input fields, or is it only text fields? Quote Link to comment Share on other sites More sharing options...
mac_gyver Posted June 24, 2014 Share Posted June 24, 2014 (edited) 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 June 24, 2014 by mac_gyver Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted June 24, 2014 Share Posted June 24, 2014 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 wrong. And even if a value is indeed not dangerous, it can still contain critical characters and cause a syntax error. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.