2

I am building a web application, in which I am required to let user enter any character(even special characters - ~!@#$%^&*()_-+=|\{}[];:'"<,.>) in an input field. To mitigate the problems caused by them, I am taking care of two things -

  1. SQL injection - using parameterized queries
  2. Cross Site Scripting - HTML escaping user input before adding it to DOM.

Is it sufficient or am I missing something?

EDIT For giving a better context, I am explaining the flow.

In my web application, user input goes directly to a database. It is fetched from the database to create HTML(also setting html elements attributes and styles) and JSON. I am escaping the fetched values from the database while creating HTML.

While creating JSON, I am not escaping those fetched values. This JSON is used by our another application to create HTML. And I am making sure that the values are escaped before inserted into HTML.

  • 1
    what do you mean "special characters"? does this include characters like \bell and \ff and \n ? – LvB May 18 '15 at 10:36
  • Sorry, I wasn't clear, I just updated the post. – Moazzam Khan May 18 '15 at 10:45
  • Can't this be solved by using prepared statements? The user input will not be able to modify the abstract syntax tree and there will be no issue for SQL injections. This only takes care of SQL injections, if you ever display this data, you need to take care of XSS as well. I would just use XSS preventing libraries for that part. A good library will allow special characters like <, ?, [ but won't allow scripts to be constructed. Take care that the combination of multiple outputs can't generate a script by putting the HTML in between in comment. – Silver Jul 4 '16 at 7:54
3

There's no such thing as special characters.

It all depends on the context that input is used within your application. Protecting against SQLi and XSS is great, however if the input is then to be used in an operating system shell call it does you no good.

Always encode or sanitize when the data is used - leave this as late as possible. For example when outputting to HTML, HTML encode at this point.

So without knowing all the output points or sinks in your application, it is impossible to say if you are missing something. If all you are doing is inserting data into a database, and outputting it to HTML (not JSON, JavaScript, CSS, etc) then if you do the correct parameterisation and HTML output encoding in the right places you are good as far as XSS and SQLi vulnerabilities go. Doing anything else with the data would require properly encoding, sanitizing or using the correct API depending on the format.

  • Thanks, I just added the information in the post about how am I going to use the data. – Moazzam Khan May 18 '15 at 11:06
-2

you put user input directly into a DB?... Bad idea (in general).

You should sanitize all Input. (so input coming from the client and input coming from the Database).

You are relying on the Client to make values safe in your example. something you should never fully trust as its outside of your control.

for the rest I defer to @SilverlightFox as his points are all valid and applicable with 1 addition. User input should be sanitized not only on display but before storage as well.

  • 2
    Why it is bad to put user input directly into a DB, If I have taken care of SQL injection vulnerabilities. – Moazzam Khan May 18 '15 at 12:36
  • because as Microsoft put it All input is Evil. Or in other words. you can not trust user input to be safe to be put into the Database until you have checked it. – LvB May 18 '15 at 12:55
  • How do you sanitize #? – Neil McGuigan May 18 '15 at 19:26
  • that depends n your environment... there not all the same. – LvB May 18 '15 at 22:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.