0

What type of attack is SQL-injection? I am confused because this type of attack is done through the client-side. However, the attackers target is a database which is "behind" a server. Most attacks from OWASP Top 10 attacks 2017 are server-side, but the attacks are performed through client-side. Can someone explain why they're classified as server-side?

  • 1
    It does not matter who attacks but what gets attacked (and maybe compromised). Thus SQL injection is a server side attacks since it is directed against the server. – Steffen Ullrich Oct 12 '18 at 17:18
4

The database is stored on the server. This means that the server is the thing which gets directly harmed during successful SQL injection (there may be secondary effects on the client, but the server is harmed first).

Therefore, SQL injection is a server-side attack first and foremost.

0

SQL injection is a server side attack because it modifies the SQL query return in the back end code for malicious intentions.

Some add-on information: ONLY Client side validation is not enough. It is a MUST to have server side input validation as well. Because attacker may capture the packet before if it is sent to the server BUT after it has been dispatched from the browser (after validation) and alter the packet again and make it malicious.

Client side attacks mainly consists of Javacript, XSS, CSRF because they are manipulating or tricking the HTML/JavaScript.

0

One easy way to think about it is to consider where a clean fix could happen. If the client is patched, then an attacker can modify their client to allow them to make the SQL injection attack. If the server is patched, then the attacker can no longer exploit the issue.

For an opposite example of a client bug: imagine the server has a feature where every user can have some arbitrary user-editable "biography" text associated with their profile, and there are numerous public places in the web UI and other clients (such as mobile or desktop apps that aren't necessarily HTML-based) that this text is shown. Imagine one of the many clients accidentally treats this biography text as HTML and allows XSS attacks. If you try to patch this on the server by disallowing HTML in the biography text, then users can no longer talk about HTML in their biographies (which previously worked fine in every other client). The vulnerability is in one client in particular, and if that client were fixed, then the issue would be cleanly solved and no longer be exploitable. (If the server knows which client is talking to it, then the server could work around the client's bug by encoding the biography into HTML before giving it to the client, but this isn't exactly a clean fix. Not to say it shouldn't ever be done as a stopgap measure, just saying this kind of work-around doesn't affect the question of whether it's a server or client issue.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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