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
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 25, 2018 at 13:25 | comment | added | Adriano Repetti | I'd also consider to invest the money you supposed to use to "...limit the impact of and reduce the risk..." to pay a professional pentest (obviously while your devs are reasonably sure they did their job) | |
| Jun 25, 2018 at 6:49 | comment | added | underscore_d | @RobinK I'm very sceptical that using prepared statements is significantly more "stressful" than manually concatenating strings together everywhere... and, frankly, who cares when it's simply the bare minimum of responsibility to have when programming using SQL? I'm not sure just giving up and adding some third-party library is going to do much more than complicate things. | |
| Jun 22, 2018 at 12:16 | comment | added | Robin K | I have used PDO with prepared statements for quite a while now, but it becomes stressful after a while. I recently started using Medoo. It's a simple, but powerful wrapper for PHP, useably for MySQL, MSSQL, SQLite and more. You should take a look at it, it really makes your life easy since you don't need to think about prepared statements anymore. | |
| S Jun 22, 2018 at 10:16 | history | suggested | CommunityBot | CC BY-SA 4.0 |
correction
|
| Jun 22, 2018 at 9:09 | comment | added | marcelm | "It is debatable whether changing table names help, but probably it won't hurt." - It can hurt your own developers down the line, surprising them every time they have to access a table that's not named the way they expect. | |
| Jun 21, 2018 at 20:41 | review | Suggested edits | |||
| S Jun 22, 2018 at 10:16 | |||||
| Jun 21, 2018 at 18:10 | comment | added | Steve Sether | Generally I agree with this, and there's a lot of good stuff here. I don't really agree that devoting time to one solution subtracts time from another. A good WAF can be setup by a systems person that doesn't have specific knowledge of the application code base. The same is true for database changes, which can be done by a DBA. The point being, peoples skills vary considerably, and each person is suited to different tasks. If you can leverage peoples skills well, you can work better as a team. | |
| Jun 21, 2018 at 17:51 | comment | added | jpmc26 | I can't endorse the blanket advice of only connecting with a particular user when needing a particular operation. That becomes impractical too quickly. If you really want, some modest separation would be okay, like separate writing to the user tables from everything else. But you need to have all queries for a single request in a single transaction. Trying to ensure that's the case for every possible code path would be an enormous burden if you have a lot of different DB users. | |
| Jun 21, 2018 at 15:11 | history | edited | Anders | CC BY-SA 4.0 |
added 77 characters in body
|
| S Jun 20, 2018 at 23:39 | history | suggested | codehearts | CC BY-SA 4.0 |
Corrected typos
|
| Jun 20, 2018 at 21:57 | review | Suggested edits | |||
| S Jun 20, 2018 at 23:39 | |||||
| Jun 20, 2018 at 21:39 | vote | accept | Phung D. An | ||
| Jun 20, 2018 at 20:08 | history | answered | Anders | CC BY-SA 4.0 |