3 ms·
50% is also what I had found on Stackoverflow (2018) - https://laurent22.github.io/so-injections/ https://laurent22.github.io/so-injections/
by laurent123456 5y ago
50% is also what I had found on Stackoverflow (2018) - https://laurent22.github.io/so-injections/ https://laurent22.github.io/so-injections/
- cmeacham98 5y agoThe top code snippet in the "latest vulnerabilities" section (as of the time of writing) is: $query = "SELECT * FROM wp_misure WHERE Id = '".mysqli_real_escape_string($link, $_GET['id'])."'"; This is not vulnerable to SQLi unless I misremember how real_escape_string works.
- laurent123456 5y agoYes it's not 100% accurate but still gives a good approximation. See there for more info https://github.com/laurent22/so-sql-injections/issues https://github.com/laurent22/so-sql-injections/issues
- wruza 5y agoI always wondered if “real_” means “now this time we’re serious” or something less funny.
- lillesvin 5y agoIt seems to come from the MySQL C API: https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-escape-string.html https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-escape-str... The 'real' supposedly alludes to the fact that `mysql_real_escape_string()` accounts for character encoding (if specified correctly) unlike its sibling `mysql_escape_string()`. So, yeah, I'm afraid 'less funny'. :-/
- acdha 5y agoI generally reject that in review because it perpetuates thinking of the problem as needing to sprinkle escape calls around rather than using a systemic fix. I’ve seen a number of cases where this resulted in various errors because the escaped value was later manipulated in some way - I don’t believe any of those were exploitable but they caused user reports of broken formatting or crashes.
- axiosgunnar 5y agoHow would a systemkc fix look like, apart from using an ORM?
- piyh 5y agoUsing bind parameters. https://docs.python.org/3.8/library/sqlite3.html#sqlite3.Cursor # Never do this -- insecure! symbol = 'RHAT' cur.execute("SELECT \* FROM stocks WHERE symbol = '%s'" % symbol) # Do this instead t = ('RHAT',) cur.execute('SELECT \* FROM stocks WHERE symbol=?', t) print(cur.fetchone()) # Larger example that inserts many records at a time purchases = [('2006-03-28', 'BUY', 'IBM', 1000, 45.00), ('2006-04-05', 'BUY', 'MSFT', 1000, 72.00), ('2006-04-06', 'SELL', 'IBM', 500, 53.00), ] cur.executemany('INSERT INTO stocks VALUES (?,?,?,?,?)', purchases)
- acdha 5y agoThe lowest level improvement: make the default query interface support placeholders, use that everywhere in the documentation, and examples. Don’t use string concatenation anywhere except examples marked as high-risk. More advanced, 90s Perl style: setup something like a taint bit on outside variables which has to be cleared using an escape function to avoid an error. OOP variant: A class system could be used to make something like execute() only accept a SqlQuery instance and that class throws a fatal error if you concatenate a regular string. That still allows someone to run arbitrary strings through whatever marks strings as safe but that requires doing additional work rather than forgetting and is easier to audit. Nicer, possibly less safe variation: implement something like Python’s __add__ / __radd__ so query + string has the string escaped automatically. More advanced: make the query method only accept constants defined at compile time with some escape hatch function which is clearly marked as unsafe: totally_insecure_query(). You need some way to combine predefined fragments for conditionals but that should be possible in most modern languages. Rust example: https://polyfloyd.net/post/compile-time-prevention-of-sql-injections/ https://polyfloyd.net/post/compile-time-prevention-of-sql-in...
- elktea 5y agohttps://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string/12118602#12118602 https://stackoverflow.com/questions/5741187/sql-injection-th... It's still not safe