August 14, 2024 at 12:00 am
Comments posted to this topic are about the item Prevent SQL Injection
August 14, 2024 at 6:57 am
Some 3rd party libraries and applications are known to be vulnerable to SQL Injection attacks (and other means of attack).
One of the great things about putting apps in Docker containers is that Docker Desktop lists the vulnerabilities it finds with their CVE number and rating.
August 14, 2024 at 5:00 pm
Crazy that there are still 3rd parties being included in modern code with this issue.
August 14, 2024 at 11:13 pm
What do you think about a "secure by default" approach by the database SDK libraries themselves. That is, things like ADO.NET (System.Data.SqlClient, System.Data.OleDb, System.Data.Odbc, System.Data.OracleClient), MySql.Data.dll, Microsoft.Data.SqlClient.dll, etc, such that by default their API doesn't allow the use of a string based SQL statement. Or in terms of the ADO.NET interface, it wouldn't allow CommandType.Text:
https://learn.microsoft.com/en-us/dotnet/api/system.data.commandtype?view=net-8.0
Instead, it would default to and require that you can only call and execute a stored procedure, thus using parameter bindings. And therefore preventing the majority of SQL Injection attacks.
August 15, 2024 at 2:24 pm
I do wish more devs were secure by default, even if that limits options or prevents upgrades of existing code. I'd like to see them refactor the code and use better solutions that don't compromise security
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply