11–20 of 117 posts
while I understand that sql injection is mostly a fault of the host programming language/developer (php in this case) and not of the dbms/dba, couldn't the latter have avoided this in part by limiting user privileges so that it was impossible to "list the internal databases, tables and password dump" e.g. "REVOKE SHOW DATABASES, SHOW VIEW" ? (I'm aware this may make impossible to use some web frameworks which rely on…
I wonder a bit that there isn't a real binary protocol for SQL. Edit: It seems there are ways to work around server-side SQL parsing: http://www.xarg.org/2011/01/is-it-possible-to-avoid-query-pa... I was thinking more about why it is allowed at all to send text-like SQL queries to a server. A binary protocol would both be simpler to handle and would have saved us from a lot of trouble. Edit: If all client-side libs (…
Of course that does not help if you construct the entire query string as text before sending it to the server, which is how SQL injection most commonly happens.
while I understand that sql injection is mostly a fault of the host programming language/developer (php in this case) and not of the dbms/dba, couldn't the latter have avoided this in part by limiting user privileges so that it was impossible to "list the internal databases, tables and password dump" e.g. "REVOKE SHOW DATABASES, SHOW VIEW" ? (I'm aware this may make impossible to use some web frameworks which rely on…
while I understand that sql injection is mostly a fault of the host programming language/developer (php in this case) and not of the dbms/dba, couldn't the latter have avoided this in part by limiting user privileges so that it was impossible to "list the internal databases, tables and password dump" e.g. "REVOKE SHOW DATABASES, SHOW VIEW" ? (I'm aware this may make impossible to use some web frameworks which rely on…
So yeah, it's the fault of the developers but it's also the fault of the people who aggressively marketed and evangelized MySQL and helped create the ditch they're just now digging themselves out of. It's a bit like the VB/Access culture Microsoft promoted back in the day, which generated some of the most hideous corporate apps I've ever seen. Yes, some developers are bad, but the company or group doing the evangelizing/marketing also needs to share some responsibility.
6661, is that his ATM pin as well?
Same guys hit Sun.com via SQL Injection as well - http://tinkode27.baywords.com/sun-com-sun-mycrosystems-vulne... Shameless self plug: Netsparker ( My startup: http://www.netsparker.com/ ) could have identified both of these vulnerabilities.
How is it different? I watched the demo video and couldn't really tell.
I wonder a bit that there isn't a real binary protocol for SQL. Edit: It seems there are ways to work around server-side SQL parsing: http://www.xarg.org/2011/01/is-it-possible-to-avoid-query-pa... I was thinking more about why it is allowed at all to send text-like SQL queries to a server. A binary protocol would both be simpler to handle and would have saved us from a lot of trouble. Edit: If all client-side libs (…
Prepared statements should afford you a clean conscience because the values never make up part of the SQL query .. unless you are using a library that emulates it, and there are libraries out there that do, so don't assume anything.
while I understand that sql injection is mostly a fault of the host programming language/developer (php in this case) and not of the dbms/dba, couldn't the latter have avoided this in part by limiting user privileges so that it was impossible to "list the internal databases, tables and password dump" e.g. "REVOKE SHOW DATABASES, SHOW VIEW" ? (I'm aware this may make impossible to use some web frameworks which rely on…
The database in this case has to share some of the blame. For years MySQL did not support parametrized queries or stored procedures (or did not promote them), and many of the people coding against it consistently claimed that they didn't need that kind of "enterprise crap" polluting their favorite DB. This gave way to a MASSIVE code base that is inherently vulnerable to injection attacks. So yeah, it's the fault of t…
BlogComment.find(:all, :conditions => ['email = ?', 'foo@bar.com'])
If you think stored procedures protect you against SQL injection, consider the following code snippet:
sql_exec("CALL InsertBlogComment('" + get_parameter("text") + "')")