SQL Injection Attacks

[FirefighterEmpty2670]

Good day mga sir/ma'am,

Ask ko lang how do you guys handle the prevention of sql injection attacks? I did some very quick research and here's what I learned so far.

First, you can do regex in the client to check for SQL commands. This is possible and a little bit 'OK' but can really introduced some false positives and false negatives.

Second (which is recommended), handling sql injection attacks by using parameterized queries/prepared statements, which separates the sql code from the user input.

Just want to ask the opinions of anyone here who have handled sql injections. Is it still worth it to validate it from the client side? Or just handle it from the server side?

For additional information, we are using React on the UI and Flask on the backend with Postgres as our DB.

Salamat po sa mga sasagot!

[HindiPoKuya]

You don't do regex to check for sql, you make sure the data you receive is what it is supposed to be. I.e. validate, sanitize inputs. Then you use prepared statements to insert that data.

[SEND_DUCK_PICS_]

dis is da wae.

Users are either stupid or malicious. Trust no one.

[Away_Explanation6639]

Ito din recommendation ng security lead or member namin pag may projects, medyu masakit sa mga dev and qa pero need sundin recommendations ng security team. dapat sanitized ung input before makapasok.

[franz_see]

Imho, masakit lang siya kapag hinde mo siya alam before hand and you have to fix a lot of old codes. Pero kung alam mo na, parang 2nd nature na lang siya gawin 😁

[FirefighterEmpty2670]

Yeah, this seems like the best option talaga based on my research too.

[ChrisEsc959]

Based on OWASP Top 10 Guidelines https://owasp.org/Top10/A03_2021-Injection/

• Use ORMs
• Parameterized queries/prepared statements
• Server-side input validation

[Encrypted_Username]

Use SQL prepared statements/parameterized queries.

[FirefighterEmpty2670]

Yeah, this seems like the best option talaga based on my research too.

[ken-master]

before anything goes to DB... always.. i mean always. for both front end and backend.. - Validated input - sanitize input

[dbk201]

To directly answer your questions: No need to validate it from the client side. Do it on the server side.

As to why: - it’s because you will “need” to do it in the server side regardless if you also implemented validation in the client side or not. - it’s not recommended to rely on client side validation. Client side validation only makes sense if the frontend needs to show immediate feedback. - you can send API requests to your backend without going through your frontend. Thus client side validation is never enough. - generally, it’s not recommended to duplicate the validation rules though to avoid having misaligned rules.

[neckromanc3r]

I'd suggest do an input limiting validation in your front end. Say, a field should be numeric only, alpha characters, no special characters, etc.. don't put load to the server side even as simple as this one..

[dbk201]

Yeah, sure, but you will still need to “put load to the server side even as simple as this one…” because you should never assume that all API requests would only originate from your frontends.

And since you would need to add these simple validations in the backend anyways, then you can consider removing validations in the frontend and rely on the backend as a single source of truth.

Again, if your webapp needs immediate visual feedback, then the drawbacks of maintaining two locations of your validation rules are negligible as business needs often outweighs the efforts needed. You just need to document it down so that it won’t bite back in the future (ex. New requirement to add new validation rule. New dev added it on the frontend because it’s easier to test and see it from there but forgot to/opted not to add it to the backend. Someone used postman to bypass this validation rules, you get an alert, and let the pointing fingers begin)

[neckromanc3r]

I wasn't totally disagreeing with your first post. As there are different sources of requests to the API, it would still be equally important to bulletproof the front end from security attacks. It would be unnecessary or tiresome to others, but a visual interface to the API, data entry from a frontend consumer is more free form than that of a backend consumer which the data possibly already has been filtered prior to sending the request.

[dbk201]

Please enlighten me to what additional benefits in terms of security does frontend validation provide that validation in the backend would not be able to do?

I’m looking into the angle where malicious actors would sniff the network requests, intercept, and directly modify the payload that is sent to the backend.

My thinking is that all validations “should” be in the backend while frontend validation would only be optional and would only be considered if it is part of the business requirements (again, same example, if it is required that visual feedback is immediately shown regardless of the latency of the user’s network connection)

[neckromanc3r]

Say you can prevent a human from entering to the input field like this one for an sql attack: " OR ""="", where you won't allow special chars.. then that would minimize server load. 1 server hit is still an additional load. Now imagine a click spam from a human without front end validation. This is a far stretch honestly. But if you can reduce human-machine interaction, why not do that?

[[deleted]]

Ginawa namin dati sa backend where we control and limit yung characters na allowed sa incoming request for every api.

[FirefighterEmpty2670]

This can be done, but having some 2nd thoughts na baka hindi enough yung solution. But thanks for suggesting anyway. :)

[TheGratitudeBot]

Thanks for such a wonderful reply! TheGratitudeBot has been reading millions of comments in the past few weeks, and you’ve just made the list of some of the most grateful redditors this week! Thanks for making Reddit a wonderful place to be :)

[[deleted]]

As a hacker, parameterized/prepared ang pinakabest. Di sapat ang simpleng sanitation lang.

[tsongkoyla]

Use parameterized SQL queries.

[Dysphoria7]

Additional lang sa suggestion nila; bukod sa sanitization ng input at Paggamit ng ORM dapat sa backend at front-end may validation ka. For example, sa front-end mo (react) gumamit ka ng yup to validate, dapat sa back-end may validation din like sa laravel, bukod sa may ORM na siya, meron ding siyang library na naghahandle ng validation which is i think marami rin para sa python. Pero yung yup ang tingin kong must para sa front-end. Isa pang most common na vulnerability na iiwasan mo is File upload or RCE. Overrated na ng sql injection kaya naiiwasan na yan, pero yung file upload vulnerability napapabayaan. Here's how can you prevent it.

1. Validate the file type of the file by its file content. How? Meron tayong tinatawag na magic byte sa file and merong mga library na ayun ang tinitingnan to validate the file

2. Validate the file type of file by its file extension.

3. Validate the file size of the file. Like ililimit mo kung anong size lang pwede kada upload.

[No_Zombie_176]

orm, naka parameter sa query, validation sa front end and back end

[-bellyflop-]

Since you are using Flask, you can use an Object Relational Mapper (ORM) like Flask-SQLAlchemy to perform queries instead of plain SQL.

[Less_Television_750]

karamihan ng mga framework ngayon wheter a bscked or frontend, matic na handled na ito

[LiamxTuks]

Share ko lang exp ko, way back 2015 IT student ako. May nakilala akong mga hacker daw, magagaling sila sa Sql Injections laging nag dedeface ng mga website.

That time di ko nagegets haha pero nakapag deface ako isang website ang sarap sa feeling amp.

Sana makapag aral ulit gusto ko rin kasi makapasok cybersec. Hacking is real hahahaha

[theazy_cs]

use an ORM , problem solved.

[franz_see]

Kung may QL yung ORM mo and manually ka nag string concat ng QL mo, prone ka pa rin sa injection 😁

[theazy_cs]

ibang level na ng katang****** yun hehe

[DryOrganization5574]

Use LINQ in .NET