1

At my workplace we're soon going to be tasked with removing SQL injection vulnerabilities from a large code base. The application was originally written around 8 years ago and after years of bolt-ons and additional features, security is finally getting looked at. We'll be moving from using the mysql_ extension to PDO and prepared statements, binding parameters properly.

We're looking at around 1100 queries, a reasonable mix of SELECT, UPDATE, INSERT, DELETE and the codebase is littered with mysql_fetch_assoc calls.

What things can I do to make the process easier to manage?

What other things can I do in addition to moving to prepared statements to prevent SQL injection?

closed as too broad by user22815, gnat, Robert Harvey, Bart van Ingen Schenau, Kilian Foth Nov 16 '16 at 14:14

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

2

Personally, I think that sitting down and plowing through 1,100 database queries and converting them to PDO would drive me crazy.

I'd opt for doing them in smaller bits, as you're working on other parts of the application. Fixing a bug? Adding a new feature? While you're in that area, convert the mysql_ code to use PDO before you do move to anoother part of the codebase.

Now, if there's truly nothing else to be done to the app besides switching to PDO, then I don't know if there's any other way other than starting from the top and converting them all one by one, and testing each one as you go.

Not the answer you're looking for? Browse other questions tagged or ask your own question.