3

Is it possible for someone to modify the JQuery code of a remote page and make it call the remote APIs in a different way than intended?

Suppose the website www.domain.com has a jquery.js script which calls an API always on domain.com passing a name and a surname:

domain.com/api?name=bla&surname=blo

now is it possible for someone to modify the jQuery from the browser with something like Firebug and call the API without name and surname for instance and thus get a whole list of people without filtering:

domain.com/api?name=&surname=

I could of course check in my API for the two parameters to be present but suppose I have no way of modifying the listening API program.

Could my jQuery script check for the domain from which the script is executed? for instance if someone saved my jQuery file locally and executed it, would it look to the remote API the same as if the jQuery was executed from the intended web page at www.domain.com?

My idea is that a jquery script is always run "locally" whether it is downloaded from the intended page or from a modified version, however some sites seem to be able to let an API be called only from the intended script.

4

You can't rely on any protection from changes in client side code, you can only do your best to prevent them (ie XSS and CSRF). Anyone can run arbitrary JavaScript code on a page as if it were run by that page itself.

Edit:

As an example, if you're using a modern desktop browser such as Chrome, right-click anywhere on this current page then click on the option to "Inspect" the element. A sub-window should pop up and will highlight the element of your choice. You'll notice that you can directly modify some of the HTML on the page through this interface. Additionally, there will be a console tab (along with other useful debugging tabs). If you go to the console tab, you'll be given a screen where you can directly run JS in the context of the page you're viewing. If you have an element selected in the Elements tab, you can change the background of that element by running the following JS code:

$0.style.background='yellow'

Multiple lines may be used (Shift+Enter) or the contents of an entire JS file may be copied and pasted directly into the page using this console window. You'll probably also notice while using it that it has a feature similar to auto complete. This makes testing and debugging JS code much easier.

It is also technically possible for the request to be simply changed in-transit by an installed browser extension or man-in-the-middle, or the request could even be made using completely different JS code that is injected. So basically the only safe bet is to perform all necessary input sanitation on the server side and only do so additionally on the client-side for the benefit of user experience.

Hopefully this thoroughly answers the question.

1

Someone doesn't even need to modify the JavaScript - they could just make a request directly to the API in their web browser.

Most sites that restrict APIs do it by having some form of authentication - this might be a header which the script sets containing a value that has previously been provided by the API. Even then, though, other scripts could call the same request, and provide the same header, and there would be no way for the server to determine that this wasn't an intentional use of the API.

This is not specific to APIs - the server only knows what information the client provides, and the client can always lie. There are ways to make lying difficult, for example, by enforcing client certificate checks, which would allow the server to verify that the client has an expected piece of knowledge (a client specific private key), but even that can't prove to the server that it is a specific client (if someone copied the client specific private key, they could masquerade as the intended client - from the server point of view, they are identical).

1
  • Might be worth mentioning that there are techniques to reduce these risks: for example tokens may have a limited lifetime, they may be tied to a specific IP and so on. – Alfred Armstrong Jan 13 '16 at 16:03
0

Yes, this can be a Direct Object Reference exploit, or even XSS injection.

Here's an example. Let's say your jQuery ajax does the following:

DeleteUserById(100);

What happens if you edit this value through the use of a Firefox plugin such as TamperData, or editing it via the developer console?

DeleteUserById(1);

You deleted the first user instead. You could then delete every single user in the database. You can modify any commands being sent from the client in all JavaScript.

This is why all security must be done server-side, not client-side. Any checking done client-side is for the benefit of user experience.

Regarding your example, it depends on the way the developers programmed it.

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.