Skip to main content
Information Security

Return to Answer

deleted 1 character in body
Source Link
SilverlightFox
SilverlightFox
  • 34.4k
  • 6
  • 73
  • 192

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

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

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.

Source Link
SilverlightFox
SilverlightFox
  • 34.4k
  • 6
  • 73
  • 192

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