I am considering using AHAH extensively on a project and am concerned about security. Couldn't an attacker inject malicious code into my response that would then be executed in the client? If my AJAX response is JSON, I don't have to worry about this because if things are tampered with the JSON will no longer be valid.
On the other hand. It doesn't seem that AHAH is any greater risk than any normal non-https request. Is there something that I am missing or what are some other thoughts?
Couldn't an attacker inject malicious code into my response that would then be executed in the client?
Couldn't they do that to a normal page that does not have Ajax? Ajax is a normal HTTP request. There is nothing new here, same security rules apply.
If they can tamper with HTML in AHAH, they can tamper with the JSON/XML/Text in those requests so it is valid.
I've used this technique here and there over the course of 4-5 years and never really had an issue with it. You'll want to be aware of any issues as would be a concern in any JS-heavy app.
If your app requests data from 'xxx.com' and 'xxx.com' isn't you, or if your server is emitting malicious HTML/javascript without your knowledge, you have bigger concerns than the choice of data-transmission technique.
There are very few security concerns with JavaScript when compared to server side code like PHP. One issue that you must be aware of in JavaScript is Dom Based XSS.
Related
I saw here that:
As you probably already know, relying
on client-side validation alone is a
very bad idea. Always perform
appropriate server-side validation as
well.
Could you explain why server-side validation is a must?
Client-side validation - I assume you are talking about web pages here - relies on JavaScript.
JavaScript powered validation can be turned off in the user's browser, fail due to a scripting error, or be maliciously circumvented without much effort.
Also, the whole process of form submission can be faked.
Therefore, there is never a guarantee that what arrives server side, is clean and safe data.
There is a simple rule in writing server application: Never trust the user data.
You need to always assume that a malicious user accesses your server in a way you didn't intend (e.g. in this case via a manual query via curl instead of the intended web page). For example, if your web page tries to filter out SQL commands an attacker already has a good hint that it might be a good attack vector to pass input with SQL commands.
anyone who knows basic javascript can get around client side.
client side is just used to improve the user experience (no need to reload page to validate)
The client you're talking to may not be the client you think you're talking to, so it may be ignoring whatever validation you're asking it to do.
In the web context, it's not only possible that a user could have javascript disabled in their browser, but there's also the possibility that you may not be talking to a browser at all - you could be getting a form submission from a bot which is POSTing to your submission URL without ever having seen the form at all.
In the broader context, you could be dealing with a hacked client which is sending data that the real client never would (e.g., aim-bots for FPS games) or possibly even a completely custom client created by someone who reverse-engineered your wire protocol which knows nothing about any validation you're expecting it to perform.
Without being specific to Javascript and web clients and to address the issue more widely, the server should be responsible for maintaining its own data (in conjunction with underlying databases).
In a client-server environment the server should be ready for the fact that many different client implementations could be talking to it. Consider a trade-entry system. Clients could be GUIs (e.g. trade entry sysems) and (say) data upload clients (loading multiple trades from .csv files).
Client validation may be performed in many different ways, and not all correctly. Consequently the server shouldn't necessarily trust the client data and perform integrity checks and validation itself.
In case the attackers post their own form.
You can turn off/edit JavaScript.
Because the user agent (e.g. browser) might be a fake. It is very easy to create a custom application to create an HTTP request with arbitrary headers and content. It can even say it is a real browser—you have no way of telling the difference.
All you can do is look at the content of the request, and if you don't check it you don't know it is valid.
Server-side validation is a must because client-side validation does not ensure not-validated data will arrive in the server.
Client-side validation is not enough because its scope of action is very restrict. The validation is performed in the browser user-interface only.
A web server "listens" to and receives an HTTP request containing data from the browser, and then process it.
A malicious user can send malicious HTTP requests by many ways. A browser is not even required.
The client-side validation, performed using JavaScript, in the browser, is an important usability, user-interface enhancement. But it does not prevent malicious data to be sent by an user that knows how to circumvent the browser default behaviour of building the HTTP request that will be sent to the server. This can be done easily with some browser plugins, using cURL, etc.
In general, it's best for EVERY piece of an app to do it's own checking/verifications.
Client-side checks are good for maximizing the user-experience and speeding up the feedback to the client that they need to fix something, and to reduce the amount of problems encountered in the server-side checks.
Then at each major point of transition on the server-side code, you should have checks in place there too. Verify inputs within the application code, preferably via whitelist input validation, and then have any interactions with the database use parameterized queries to further ensure problems do not occur.
You should perform server-side validation on any data which, if invalid, could be harmful to anyone other than the entity posting the data. Client-side validation may be suitable in cases where invalid data would have no ill effects for anyone other than the entity posting it. Unless you can be certain that the ill effects from bad data will not spread beyond the entity posting it, you should use server-side validation to protect yourself against vandals or other rogue clients.
Client sided validation is for saving the client from entering wrong data. Server sided validation is for saving the server from processing wrong data. In the process, it also introduces some security into the submission process.
Client side validations presuppose a safe browser, a client side language, or HTML 5. All these elements could be disabled, partially unusable, or simply not implemented. Your website have to be used from every person, with every browser.
The server side languages are safer, and -if they aren't bugs- the validation will be surely safer and right.
Buddy , Suppose if a person turnsoff the javascript in his browser , the validation became dead . Then if he post some malcious content through that form to the server side . It will lead to serious vulnerabilities like sql injection or xss or any other type of problems . So beware if you are going to implement a client side javascript validation .
Thank you
I am using JQuery and Javascript extensively in my new project including form validation because I don't want to burden server using PHP validation. So I am restricting my site from the people who disabled Javascript on their browsers. I am trying to redirect them using meta tag:
<meta http-equiv="refresh" content="2; URL=../../enablejs.html">
I assume that this is safe because if javascript is not enabled they will not be able to access my site.
But still I have a doubt over this and need your advice. Is it completely safe? If not what are the area I need to concetrate?
This is a terrible, terrible idea.
because I don't want to burden server using PHP validation
You mean, you don't want to burden yourself with implementing it :)
I can relate. Everyone hates doing stuff twice. But server side validation is not a negotiable extra; client side validation can be easily circumvented and is for user convenience only. Server side validation is always needed for safety and security.
Apart from it being a bad idea, there is no way of reliably excluding users who have JavaScript turned off. JavaScript runs on client side, and its presence or non-presence can be easily faked to the server.
Client-side anything is never ever safe. You always need server-side validation. It's not a "burden", it's a necessity. I don't even need your website to submit (unvalidated) data to your server, in the end it all just boils down to HTTP requests. If you do not validate everything the user does on the server, you have no security.
I am using Jquery and Javascript extensively in my new project including form validation because I don't want to burden server using PHP validation.
That shouldn't save a significant burden. It should give faster feedback to users though, which is good.
So I am restricting my site from the people who disabled Javascript on their browsers.
That is a waste of time. The proportion of submissions in that which will be from users with JS disabled will be tiny.
I am trying to redirect them using meta tag
That's a very user hostile thing to do.
I assume that this is safe because if javascript is not enabled they will not be able to access my site.
If you mean that it avoids the need to write server side validation routines, then you are wrong. If someone wants to attack the site (rather then submit bad data by accident) then they can construct HTTP requests manually.
No that's not safe. Client side validations are nowhere safe. With javascript enabled anyone can bypass your validations. Using chrome console I can probably alter any text on your input boxes or any other input method without you validation noticing it.
Use server side validation or you're screwed.
No, this is not safe. Never rely on the browser for form validation. Form validation in the browser should only be to improve user experience, not to protect your data. You need to add some PHP validation.
Also, are people who have JavaScript disabled not supposed to use your site? You should make JavaScript degrade gracefully so that your site is still usable without it.
Using client side validation is a recipe for disaster "never ever trust clients input" clients inputs are GET (URL included), POST, FLash ...
All inputs should be validated by server side scripting language like PHP, ASP.net, java ...
If you use PHP then check http://www.phpclasses.org/ and look for form validation scripts and Cross-site scripting (XSS). Or use validation classes offered in frameworks like zend, codeigniter
http://en.wikipedia.org/wiki/Cross-site_scripting
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why is client-side validation not enough?
What is the purpose of using the both validations at the same time? Because it's extra burden on the server for validating the form inputs in php if javascript validation is successful. Can not we use a flag and set or unset its value depending upon whether javascript validation is successful or not? And if the flag value is set, we will skip the php validation. Is it not possible? If it's not possible can you explain with a valid real life example? Or can a user modify the value of the flag even if we pass it in header?
Waiting for some logical answers.
Thank you.
Validating with JavaScript saves you a trip to the server, and creates a nice responsive user experience.
Validating with PHP is necessary so you don't get broken data, or worse (the user could disable JavaScript or post data to your PHP application in a number of ways).
JavaScript can be disabled by the user. It can also be manipulated because it is client side.
One thing to always keep in mind, never trust the users input. Even if you trust the users, or if the website is limited to a very small known to you audience.
So always keep server side validation.
Client side validation is for usability, so I would recommend you keep that too.
The purpose quite simply is the safety.
Javascript validation is happening on the client side - in the users browser. There are no problems to disable or edit the validation to my liking by using a tool like firebug, for example, or to disable it at all by disabling javascript in my browser.
PHP validation, on the other hand, is done on the server side and the user can't interfere with that.
To sum it up, and how I like to think about it - Javascript validation is for the ease of use for the client, PHP is for actual safety.
You can never trust user input. JavaScript is a utility for improving user experience, not your first line of defense against malicious user behavior. JavaScript itself can be used to bypass all JavaScript validations; all someone has to do is type this command in console:
document.forms[0].submit();
Now I am not sure what is with the idea of using flags. But it just as easy for someone to "set" the flag manually if he/she can JavaScript validation.
And if you think server side validation causes burden on the server, you're being ignorant (or lazy, perhaps).
Client side validation is primarily for user-experience and basic-validation.
While writing server side code, you should write validation to ensure security and to make sure the requests are not tampered in between.
As you might know, browsers allow the user to disable javascript. In such a case, client side validation code will not be executed. If there is no server side validation, this will create inconsistency in your application.
For example, if there is an input text field for which you application is expecting an integer value and the user inputs a non-integer value, your application is bound to misbehave and if you are using a database, it will throw some error
To strengthen a point the other answers may have implicated: Not only is it possible to bypass JavaScript in a browser, but it is possible to send data to your server without even visiting your website, if an attacker analyses the requests send to and from your website.
This can be done either by a tool that manipulates the GET / POST requests (thus even using a valid session) or a tool that builds its own requests.
JavaScript validation is to help your regular users to enter well formed data, server-side validation protects your server / your data integrity
I am creating a web application that uses JQuery's AJAX calls as it deals with all of the browser inconsistencies.
However, as the code is very much easily readable from the browser I have has concerns about what security measures I can use to protect the web application from attack.
I will be obviously doing authentication checks for the server side code to ensure that they have access to the data that they are trying to access. However, I have also been trying to look into ways of stopping CSRF attacks as well as looking into ways of 'obscuring' the code so it is not easily readable via View Source in the browser.
What steps should I be taking to ensure that security is at a good level?
Also is injecting data into a jquery script via PHP a bad idea?
Thanks!
There's no easy answer to your main question. You should read the OWASP guide on CSRF prevention and go from there.
And there's plenty of options out there for obfuscating javascript, but none of them will increase the security of your code. If an attacker really wanted to read your obfuscated code, he could just pick through it by hand or write a parser for it and simply de-obfuscate it. Not a viable security technique.
Also is injecting data into a jquery script via PHP a bad idea?
As long as you have no problem with the world seeing that data, no it is not a bad idea. If the data is sensitive, you'll probably want to keep it server-side, or hash it with a salt and then insert the hashed value into the script. Of course, this hash is rather unusable client-side because you must not include your salt in anything client-side (this would defeat the purpose of obfuscating the data in the first place). If you want to make use of that data, you'll need to ajax it back to your server and process it there.
I really like the idea of validating forms client-side before doing so server-side. If the client's validation passes, I can use Javascript to submit the form.
However, I have heard that some specialized browser, like browsers for the visually impaired, don't support Javascript. Therefore, those users won't be able to submit my forms. Should I therefore avoid what I just thought of doing, or is it alright?
EDIT: (In response to answers): I guess I didn't explain that, but I was planning on doing server-side validation in addition to client-side. Sorry!
Thanks
Javascript is a nice touch to validation. It lets the user know right away that something is wrong, plus it minimises potential calls to the database.
If there are browsers out there that disable javascript for accessibility reasons, you shouldn't worry to much. That's what the server-side checking helps with.
So you should use both, and test with javascript turned on or off. NEVER use javascript as a sole validator - you could just turn javascript off in your browser and the POST data would go through!
You should do both client-side validation and server-side validation. Everything you catch with client-side validation is an opportunity to improve the user experience for your users and tell them exactly what is missing or wrong before they submit the form. If, for any reason, javascript is not enabled, you will still validate on the server (as you always should) and can return errors through the form response from the server if you have to.
So, it's always a good idea to use client-side validation if available.
Is client-side validation smart? Yes, clean input is better for performance than input that will error out.
Great UX? Yes, it's important for a user to get quick, relevant feedback.
Safe? No. Not at all. Hackers don't use your interface to hack your site.
More and more browsers can be site-selective about running JS.
Lastly, if you are concerned about equal access, your best bet is to build accessible versions of the site.
Client side validation often improves user experience, as the user can immediately see whether his data is valid or not.
If it is some simple validation, like pattern matching or length checking for passwords, definitely do it. But of course it is not a substitution for server side validation, it is not a security means in any way. Never trust user input.
Integrate the client side validation in an unobtrusive way, so that form submission still works if JS is turned off.
"Both And" is the answer. Validate client side as a convenience and as a way to better the user experience, but you should always validate server side.
Browsers without JavaScript won't execute the JavaScript at all, so they will still be able to submit your form. Don't worry.
Client side validation is done by interceptin the normal submit event and return true or false based on whether the form is valid. In this way, when javascript is not enabled, the submission is not intercepted and proceeds as normal.
It is one of the easiest things to degrade gracefully, fortunately :)
Not sure we can say it's smart to handle form "control" before submitting : this is "only" client comfort, as these controls... are just not valid from the security standpoint. So this is adding coding efforts for no added value from the security prospective. But this is adding effort for client comfort. And THIS is smart.
The simple way :
No client-side control at all, only server side. No need that js is enabled on the client-side.
This is the point that shall be always enabled and full security valid.
The intermediate way:
Implementing the simple way and adding some javascript "controls" on top, "hand coded" or using js librairies. This is the fastidious way as this is adding a layer on top of the existing server core code, and generally means some server-side code changes or refactoring. So this is the worst way according to me. But this is a good way to learn and understand the client-server exchanges. Painful but useful.
The best way:
Base all your efforts on server-side validation but make sure, from the coding starting point, to be able to embed also the "nice to have", eg. the client-side nice "controls". Which means you have to think of your code architecture before starting writing any line. How to do that ? use Ajax coded forms on the server side. Which suggests the way of coding ideally with specific php form classes. For example, ZendFramework is providing such kind of possibilities using either dojo or jQuery.
Its always better to have "Cleaner" data passed into the server.
Prevents errors and malicous data.