2

Are there any possible ways by which a malicious user on a web application can manipulate the input that is sent by the front-end of web application (not talking about the FORM DATA, of course) but the requests that are sent like for e.g., when I allow him to edit his profile or his content, he may manipulate the IDs (userId or the contentId) so that he may maliciously do evil with other users content? These inputs are fixed on a webpage & are not editable but still can the users manipulate them?

Is it possible that users may do harm in this manner? How can I safeguard my application against this? Besides, verifying user's identity and his contents/properties on the application prior to allowing each of his actions.

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
Rajat Gupta
  • 25,853
  • 63
  • 179
  • 294
  • The answers are correct, but consider also: there is no reason for you to assume that your web application is even the program that is sending the data... – horatio Mar 02 '11 at 15:05
  • could you please clarify your point a bit...I could not understand what you meant by this statement..Thank you! – Rajat Gupta Mar 03 '11 at 04:52
  • It means the user could write a script that sends requests to your application. It basically means you have to expect *anything* to be fed to your application. – ThiefMaster Apr 20 '12 at 07:10

2 Answers2

8

Yes of course. Anything that comes from the client can be modified and cannot be trusted at all.

You need to do server-side checks if the user is editing his own profile or something he's allowed to edit.

For things like editing the profile you could simply use the userid stored in his session though (assuming it's secure, i.e. stored server-side or in cryptographically signed cookies). Only let data go through the client if it's necessary - if the data is already available on the server, you don't even have to give the user the feeling that he might be able to tamper with it. Even though it could be used as a honey-pot - but that's not really the purpose of most webapps...

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
  • Security is only as good as the serverside's security. Think of the server as your security, as the browser's main focus is to ensure the security of the client. – Zoidberg Mar 02 '11 at 13:16
  • Yes. Use client-side validation only for convenience, never for security. – user Mar 02 '11 at 13:19
  • Yup. I think the comment would fit more to the question instead of my answer though. – ThiefMaster Mar 02 '11 at 13:19
  • @Michael: Indeed. But you can for example do fancy validation in Javascript and just throw an "something is invalid" error in the server-side validation in case all your users will have JavaScript enabled anyway. That might save you some time depending on how your validation is done (manual/validation framework/etc) – ThiefMaster Mar 02 '11 at 13:20
  • @ThiefMaster: That's what I mean. I would rather provide a useful error message to the user from the server side as well if input fails server-side validation, but if the web site requires Javascript to function anyway, then it's probably safe to assume that anything that hasn't been checked client-side is injected. But the point is, *you still have to validate all inputs on the server side*, or you cannot trust them to have been validated at all. – user Mar 02 '11 at 13:28
  • 1
    Given that you must ultimately depend upon the user's logged-in status, there is actually no point in putting his id into the form, unless you are laying a trap for mischievous users looking to test your defenses (which actually sounds kind of fun). ;-) – David Weinraub Mar 02 '11 at 14:42
2

Yes, it is possible and it is a real danger.

There are two things you can do:

  1. Implement an access control / permission system which controls which data records a user can access or modify.
  2. Store information that is none of their business in a session object on the server.

(By the way, these are not exclusive options, ideally you should do both.)

Both solutions still leave you prone to session hijacking though, which is a different, more global problem.

biziclop
  • 48,926
  • 12
  • 77
  • 104