0

I'm wanting to send variables to a waiting PHP document using the POST method, but these variables are used as arguments to do things such as delete, hide, etc.

The problem is that I only know of two ways to do this:

  1. An href attribute where you build your URL
  2. Using an XMLHttpRequest

There is a security risk with both of these methods as they will show the variables within the source code. This could lead to someone having control over other user's data through manipulation of the URL. All they would need is the readily available variable and the user name.

function usrVisToggle(){
    var adjNum = Number(document.getElementById('lineNum').value);
    var adjSend = new XMLHttpRequest();
    adjSend.open('POST', 'https://000webhostapp.com');
    adjSend.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    adjSend.send('argument=4&adjusted=' + adjNum, false);
    location.reload();

The above is an example of how my code works right now.

The problem is within the argument=4. This will show in the source code and once you get the argument you can begin toggling everyones' data to be visible/invisible. Building your own URL to use in HTML poses the same risk.

What would be some ways around this?

jonroethke
  • 1,152
  • 2
  • 8
  • 16
Napalm
  • 1
  • 2
  • If the user shouldn't have access to it, it shouldn't come from the client in the first place. – Barmar Jan 18 '19 at 21:02
  • 2
    Authenticate the user making the request, and then make sure the user making the request is changing only their own data. – Alex Howansky Jan 18 '19 at 21:03
  • Even if you hide it in the source code, there's nothing stopping a user from manipulating it. You need to implement authentication checks on the server that prevent users from manipulating someone else's data. – Barmar Jan 18 '19 at 21:04
  • I will look into this. Thank you very much for the quick and helpful feedback! – Napalm Jan 18 '19 at 21:16

2 Answers2

0

Not two minutes after this post I realized that instead of focusing on the manipulation codes, I could just make an impossibly hard to guess user code and save to database. This renders the argument=4 almost moot because you would have to break into the database to steal the information, or get lucky and guess a really long string that relates to the user.

Napalm
  • 1
  • 2
  • 2
    This sounds like [Security through obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity). – GrumpyCrouton Jan 18 '19 at 21:23
  • Very interesting read, thanks for bringing my attention to it! Although it seems closer the the Security through minority at the bottom of that wiki as even if you knew the method of security you would still need to figure out the string(however long you wanted that to be). I can see how brute force attacks could still pose a risk to this type of protection, and as we know with bitcoin, there's a lot of brute force computing going around. – Napalm Jan 18 '19 at 21:36
  • You may be right about that. Brute force may be a problem, but how much damage can someone do if they did somehow guess a code? – GrumpyCrouton Jan 18 '19 at 21:38
  • In my instance they could delete data, change the status of the data from adult to non(cursing and stuff), harass someone with constant changes to their data, etc. I see what you're getting at though, the security measures should relate to the sensitivity of the data and what you can do with said data. pictures of kitties wouldn't need near the protection of say, bank account data. – Napalm Jan 18 '19 at 21:43
  • That could be pretty bad, but what are the chances someone will _try_? – GrumpyCrouton Jan 18 '19 at 21:44
  • Are you kiddin' me? lol, it's the internet. 100% ;) I can also see a point here. The protection should increase with the traffic. – Napalm Jan 18 '19 at 21:45
  • Well, a possible solution to this for every request with an incorrect ID, you could log the users IP address, and after a certain amount of fails (I'd say like 10-20, you don't want to effect people just accidentally mistyping something) you could block them from more requests for some time, or lock them out until they contact your support team manually. This will work if they just change their IP too, because this one would also get blocked. And if it's a REAL problem, you can block IP ranges to try to block specific abusers. – GrumpyCrouton Jan 18 '19 at 21:47
  • That seems like a really good thing to look into as well. I've also seen some sort of system popping up on forums recently where the website will request the user side to complete some sort of computation(it might simply be a wait function) to block against brute force attacks as a sort of reverse DoS. You've gotten me thinking friend. – Napalm Jan 18 '19 at 21:53
  • Or even a simple Captcha system could prevent brute forcing depending on how the request is made. – GrumpyCrouton Jan 18 '19 at 21:55
  • Yeah, captchas would work as well. However, I personally don't like them, they have a bad habit of getting in the way of the user experience(I'm also very bad at them for some reason.) Once for login is always fine, but if you're just trying to click a button I wouldn't want it. And, I wouldn't use a website that had something like this implemented. – Napalm Jan 18 '19 at 22:02
  • Then record IPs for actions and after a certain amount, show a captcha – GrumpyCrouton Jan 19 '19 at 23:08
0

You cannot trust on the client side, everything you hide on JS code you can undo just using a CURL command. That said, you can encrypt the params just to obfuscate and hide interactions.

Walker Leite
  • 223
  • 1
  • 7
  • Yeah, I realized that I couldn't trust client side. That's why i was looking for ways around this method. Thanks for the feedback though! I appreciate it! – Napalm Jan 18 '19 at 21:12