-1

Server Side programming languages have workarounds to prevent sql injections
eg:

mysql_real_escape_string("sql query here");

Suppose html returns every quote as \' or \" instead of just ' or "
Even if server side language is not being used, JavaScript prints \' as just '.
What are other problems that would arise due to this?

Ebenezer Isaac
  • 772
  • 1
  • 8
  • 31
  • 3
    Why should the browser "fix" possible problems of what-ever back end software/language you're using? – Andreas Jun 26 '19 at 16:50
  • 1
    HTML is a markup language, not a programming language. The programming language is in charge of things like escaping input. – DrCord Jun 26 '19 at 16:51
  • Ofc HTML is a markup language, but this just fixes a lot of vulnerabilities once for all right? – Ebenezer Isaac Jun 26 '19 at 16:54
  • Instead of writing unsafe code, you should secure it with the current methods to prevent SQL injection. It's not difficult and pretty trivial. And you don't have to use a browser to make an HTTP call to the server BTW – Alon Eitan Jun 26 '19 at 16:55
  • "Fixing" the apostrophe is a workaround. Instead you should fix software to not create SQL commands from raw strings and use proper prepared statements. The real question is why SQL libraries allow unsafe queries (HTML is not the only input vector - what about Android apps? Desktop apps? Minecraft (yes, minecraft is backed by an SQL database)) – slebetman Jun 27 '19 at 00:24
  • Browsers (and different versions of these browsers) would have to be standardized. and if they are not then the security of a server/db would be left to a random browser. If a malicious user uses a malicious browser, or a console app to simulate the DOM then they could run malicious code on your server. – Frank Navarrete Jun 27 '19 at 00:26

2 Answers2

6

' has special meaning if you try to insert it into an SQL query.

' doesn't have special meaning if you try to insert it into an HTML element (and if you submitted don't and expected the result to be <span>don't</span> then you wouldn't like to get <span>don\'t</span> back!)

The browser has no way of knowing what is going to be done with the data after it is sent to the server. It just sends the data it is given using the standard encoding it is told to use by the enctype attribute.

Protection from XSS, SQL injection, and other kinds of attacks can only be reliably done by using appropriate handing of data for the particular environment it is being injected into.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • And there was also the DEPRECATED `magic_quotes_gpc` configuration that was removed in PHP 5.4 that was supposed to prevent SQL injection – Alon Eitan Jun 26 '19 at 17:03
3

Easiest way i can think of explaining this is to get you to imagine a web page like a house with a home security system, where the doors and windows are the html, and the security system with all it's sensors is languages like java, .NET/C#, php, etc.

If the doors were made so that they could sound the alarm any time it thought the lock was being picked, and windows could tell when their glass was smashed on their own, yes that would be cool.

But now what do you do if you have a burglar cut a hole in the wall and enter your house without touching either the doors or windows? At that point, they have bypassed your door/window security (HTML), and all that's left protecting your house is the motion/infared sensors from the security system (php/java/c#).

This is the issue we would run into. If HTML had the added capability of preventing sql injections and nothing was done on the server side (ie: no motion/infared sensors in the house), what is left to prevent users from bypassing the HTML page and sending malicious stuff to the server directly?

MathewH
  • 67
  • 1
  • 8