4

I've been attempting to do some research on this topic for a while, and even cite the following Stack Overflow threads :

Javascript Hijacking - When and How Much Should I Worry

JSON Security Best Practices

But my basic problem is this.

When I am building my web applications, I use tools like Fiddler, Chrome Developer Tools, Firebug, etc. I change things on the fly to test things. I can even seem to use fiddler to change the data that gets sent to the server.

What stops someone else from just opening up my webpage and doing this too? All of the jQuery validation in the world is useless if a user can just hit F12 and open up Chrome Developer tools, and change the data being sent over the wire, right?

I'm still relatively new in this field and this just has me very concerned as I see "Open" Protocols become more and more ubiquitous. I don't understand SSL yet (which is on my list of things to begin researching), so perhaps that is the answer and I just haven't dug deep enough. But the level of flexibility I have over manipulating my pages seems very extreme - which has me very concerned about what someone malicious could do.

Community
  • 1
  • 1
Ciel
  • 17,312
  • 21
  • 104
  • 199
  • 2
    You do not even need to hijack the page, I can open up a command line on linux and submit anything to your server. Validation on server is needed. – epascarello Feb 01 '13 at 16:37

6 Answers6

9

Your concerns are indeed justified. This is why you should always validate everything on the server. Client-side validation should only be used for UX.

Manu Clementz
  • 1,807
  • 12
  • 19
1

JavaScript's security is, in a nutshell, based around a trusted server. If you always trust what code the server sends you, it should be safe. It's impossible for a third party (like an ad supplier) to fetch data from the domain it's included on.

If the server also sends you user generated content, and in particular user generated code, then you have a potential security problem. This is what XSS attacks focus on (running a malicious script in a trusted environment).

Client side validation should focus on easy of use, make it easy to correct mistakes or guide the user so no mistakes are made. The server should always do validation, but validation of a more strict nature.

Halcyon
  • 57,230
  • 10
  • 89
  • 128
1

Validation should always happen Server Side, Client Side Validation is only valuable to make for a more convenient experience for the user. You can never trust a user to not manipulate the data on their end. (Javascript is ClientSide)

Next if you are wanting to secure your service so that only user1 can edit user1's profile you'll need to sign you JSON request with OAuth (or similar protocol).

abc123
  • 17,855
  • 7
  • 52
  • 82
0

yeah nothing can stop anybody from interfering the data that is being sent from the browser to your server and that's the reason you shouldn't trust it
always check the data from the user for authenticity and validity

also with it you can check and interfere with the data that big sites like google and microsoft send back and you might get an idea.

Parv Sharma
  • 12,581
  • 4
  • 48
  • 80
0

You have to assume that the client is malicious-- using SSL does not prevent this at all. All data validation and authorization checking needs to be done server side.

antlersoft
  • 14,636
  • 4
  • 35
  • 55
0

Javascript isn't going to be you only line of defense against hackers, in fact it shouldn't be used for security at all. Client side code can be used to verify form input so that users trying to use the page can have faster response times, and the page runs nice. Anyone who is trying to hack your page isn't going to care if your page works or not. No matter what, everything coming into your server should be verified and never assumed as safe.

Michael Timbrook
  • 63
  • 1
  • 6