Timeline for How to limit the impact of and reduce the risk of SQL injection for existing website?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 28, 2018 at 18:05 | comment | added | curiousguy | "The only correct way" I strongly disagree with "only correct way". There are many ways corrects ways. (They end up doing something equivalent.) | |
| Jun 28, 2018 at 7:46 | comment | added | phresnel | @curiousguy: It depends on the whole platform and its requirements. For basic authentication requirements and just a few ten thousand users, a simple map/dictionary/associative array loaded into a daemon's/service' memory and stored in a CSV, XML or JSON file could be the right thing. An implementation of this would be simple, or use CouchDB, for instance. Endless possibillities: It's basically just a data structure and algorithm choice, tho' I realise that even "Bachelors"/"Masters" in Germany seem to have forgotten data structures and algorithms. For starters: bit.ly/2lEy9GL | |
| Jun 24, 2018 at 22:30 | comment | added | Charles Duffy | @curiousguy, ...you don't get SQL injection in a Datalog database. Then again, that tends to be because the recently-popular implementations (DataScript, Datomic) take LISPy datastructures as query specifications -- not strings -- so there's no temptation to try to build those queries via string concatenation. | |
| Jun 22, 2018 at 23:27 | comment | added | curiousguy | @phresnel What kind of database should be used instead? | |
| Jun 21, 2018 at 19:20 | comment | added | Guy Schalnat | Ok, there may be other options, but if the OP is already running too short on programming time, those other ways are just going to be slower. Prepared statements is probably the most practical way to close the hole. | |
| Jun 21, 2018 at 13:29 | comment | added | phresnel | I find "the only correct way" a bit grandiose, or ambiguous at best. Maybe using an SQL-database was incorrect from the beginning? | |
| Jun 21, 2018 at 8:36 | comment | added | Georg Patscheider | It might also be a good idea to make code reviews part of your process, e.g. review everything that is merged to the main or production branch. Have coding guidelines that define how things should be coded and what is prohibited (e.g. it should not be allowed to string-concatenate parameters into a SQL query). This will keep new vulnerabilities from being introduced after you fixed the current ones. | |
| Jun 21, 2018 at 7:46 | comment | added | Xenos |
Take care with restrictions, since it can quickly impact legitimate users knowing that the issue here concerns a GET request, so could be injected in a <img src=""/> tag so all users seeing the page with this tag will trigger a request, and might end up being locked down by the website.
|
|
| Jun 20, 2018 at 20:05 | history | answered | trietend | CC BY-SA 4.0 |