View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000967 | Composr | core | public | 2013-01-08 17:48 | 2013-03-20 12:38 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Severity | Feature-request | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0000967: Additional SQL injection prevention | ||||
| Description | If Composr's 'query' method is executed, implement two strategies when DEV_MODE is on, to help programmers write more secure code... 1) Check the query doesn't match a pattern that query_select/query_update/query_delete could handle. If it does, trigger an error. i.e. if the WHERE clause is just something like... WHERE a=2 AND b=3 then that is array('a'=>2,'b'=>3) for one of the specialist query functions, manual SQL is not needed. Manual SQL represents an increased security risk. 2) When db_escape_string is called, keep a global memory of what strings were passed. Then when the query method is called, analyse the SQL for all embedded strings (i.e. an SQL parse), and ensure each is in the list of strings that has been passed through db_escape_string. If a string is not, use PHP's backtrace functionality to find the line of code that was called, and analyse it. If that line of code does not include '<string>' (i.e. statically, hard-coded) then flag an error, as dynamic SQL has not been escaped properly. | ||||
| Tags | No tags attached. | ||||
| Time estimation (hours) | 3 | ||||
| Sponsorship open | |||||
