View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000502||SOGo||Backend General||public||2010-03-19 00:07||2016-12-09 10:47|
|Fixed in Version||3.2.5|
|Summary||0000502: SQL injection vulnerabilities|
The backend does not use prepared statements and bind variables when performing SQL queries --- rather it constructs literal statements by interpolating variables into format strings. In doing so, few (if any?) free-form string values are properly escaped before interpolation, so the code if rife with opportunities for SQL injection attacks.
In fact, it is quite trivial, for example, to alter the database via the username field on the login/front-page. Thus, one need not even be an authenticated user to attack the system.
|Tags||No tags attached.|
Can you provide samples of what you state above? I don't exactly see how one could inject SQL from the login form, unless the authentication is made via an SQL view...
Yes, indeed --- SQL injection from the login form is possible when SQL authentication is being used. (Sorry I didn't say that explicitly; that's what I've been working on setting up.)
For an example, the following "Username" will delete the everything from the folder info table (given the default/suggested name and a postgresql db):
'; DELETE FROM sogo_folder_info; SELECT '1
That's the first SQL injection exploit I have ever written; I imagine people who like this kind of thing could come up with something more creative.
This has been fixed for SQLSource - have you spotted any others?
Thanks for the speedy fix.
I took another (quick) look --- basically by grepping for "sql" to look for SQL statements. I can't say I saw anything trivially exploitable, but I can't say everything else is safe, either. I don't know the codebase well enough to know, for example, what happens to a string typed in a addressbook search-bar.
Whenever I see code that does simple string-substitution to perform SQL queries, I get nervous, because such code becomes increasingly difficult to audit for such vulnerabilities over time. (And, performance tends to suck as well, because the DB has to parse/prepare/optimize each statement over and over again with every query.)
340ddf0ae6cf6a7aeb16d7b77f237bee7bff16a3 contains other safe measures. Closing for now since after an audit of the code, things seem clean.
|2010-03-19 00:07||maddog||New Issue|
||Note Added: 0000784|
|2010-03-24 21:05||maddog||Note Added: 0000793|
|2010-03-24 21:23||ludovic||Note Added: 0000794|
|2010-03-25 00:53||maddog||Note Added: 0000796|
|2016-12-09 10:47||ludovic||Note Added: 0010978|
|2016-12-09 10:47||ludovic||Status||new => resolved|
|2016-12-09 10:47||ludovic||Fixed in Version||=> 3.2.5|
|2016-12-09 10:47||ludovic||Resolution||open => fixed|
|2016-12-09 10:47||ludovic||Assigned To||=> ludovic|