I am learning about cybersecurity and have read about client-side exploits. I know they are vulnerabilities/exploits and they target the client instead of a server. What are some examples of this and how do they work?
Add a comment
|
2 Answers
In the classic client/server architecture, there is the server which serves requests initiated by the client, and the client which makes said requests. An example of the client/server architecture is the web, where a web server communicates with a web browser (the client). A client-side exploit is thus one which attacks or influences the client. It is distinguished from a server-side exploit which attacks the server.
An example of a client-side exploit would be malicious JavaScript taking advantage of a bug in a browser. An example of a server-side exploit would be SQLi, which attacks a server's handling of its database. Client-side exploits are not unique to the web, since there are more client/server architectures out there. Attacking a vulnerability in PuTTY (a Windows program used for managing remote servers via the SSH protocol) would be an example of a client-side exploit that does not involve the web or web browsers.
-
Would a malicious PDF or malicious word documents count? I am looking into client side exploits that are done without a server such as a PDF sent by email– SamathaCommented Jul 7, 2019 at 1:47
-
@Samatha Yes, an attack against a PDF client would be a client-side exploit.– forestCommented Jul 7, 2019 at 1:49
-
Do you know of any other attacks that would be considered a client side exploit– SamathaCommented Jul 7, 2019 at 1:52
-
@Samatha Have you tried doing a web search for the term? There are a lot.– forestCommented Jul 7, 2019 at 1:53
-
Yes however could not find anything of importance do you have any resources?– SamathaCommented Jul 7, 2019 at 1:54
Client side exploits are not necessarily attacks on the client!
Many web servers invoke authentication and security via client side functionality. For example they may send back a sub-path or ID in a query response, expecting the client code to hold and reuse this content appropriately (cookies work this way). The problem is that the client code and data is subject to modification by the client user, allowing them to send back different ID's, offsets, paths, or whatever not intended to happen or accounted for by the server.
Years ago it was very common for an online store to send back the shopping basket data to the client to hold until checkout, including the price of the different items. It was very easy to alter the prices on the client before submitting for checkout. If the server failed to re-validate the basket, and many didn't, the purchase would go through with the client side altered price.
Other examples included using someone else's ID in a 3 tiered client-server-database where the server validated the client ID at logon but the server-database connection was actually only an internal fixed ID with the server passing on the ID echoed by the client for recording. After initial authentication of ID #1, the client side data could be altered to ID #123 which would be passed on by the server because it only checked it the first time or it used an entirely different field to hold it, different from the authenticated ID.
These are only two examples, but both were real!
answered Jul 7, 2019 at 2:24
-
Yeah however i was asking about clients not a client side attack involving a web server– SamathaCommented Jul 7, 2019 at 2:38
-