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.
Related
I have a public form that publish POST data to a PHP script.
This form is not located on the same domain, and doesn't use PHP either so the protection cannot be built around PHP session.
The goal is to allow only this form to post on that PHP script.
How do I provide more security for checking source of the request tells how to implement CSRF protection using PHP session but I wonder how I could do to protect mine without it? Is it possible?
POST requests are harder to fake compared to GET requests, so you have that going for you, which is nice. Just make sure you're not using $_REQUEST in your script.
You cannot use sessions here, but the principles are the same - you gotta implement some kind of a "handshake" between a form and your PHP script. There are a few different approaches if sessions are not an option.
The simplest thing to do would be to check http referrers. This will not work if the form is on http and script is under https, and also can be overcome using open redirect vulnerability.
Another way to go would be captchas. I know, not user friendly or fashionable these days, but that would make request forgery much harder, as hacker could not make his exploit work behind the scenes without any user input. You should look into reCAPTCHA (google's "I am not a robot" checkbox): https://www.google.com/recaptcha/intro/index.html
This is a tricky situation, because form on one host and script on another is basically CSRF in itself, so you want to allow it but only for one host. Complete security without any user interaction might be impossible here, so just try to make it as hard as possible for a would-be hacker to mess with your script, or suffer on the UX side. Personally i would go with reCAPTCHA.
I can't seem to find an almost exact question so I might as well ask away.
Is it really a standard practice to send variables from Javascript to PHP? I'm planning to send array to PHP after some several assessment within Javascript - passing variables here and there...only to be combined again as an array, and as I've said, will be passed to PHP. Am I missing something? I hardly see any tutorials to do this, mostly the other way around - that is, PHP array to Javascript. Makes me think, maybe it just isn't being advised to do Javascript to PHP due to security reasons.
Simply put, will sending Javascript array to PHP that will later on be saved to database be dangerous? I haven't really FULLY read how to do it, just scanned the very few that I could find...json stringify, $_POST, json encode, json decode. If it is fine to do JS to PHP passing, and since it is related to my question anyway, can someone point me which of those mentioned is best for better security? Thanks!
Security isn't really an issue at this point: JavaScript runs on client side, so anything that could go wrong here could be easily faked by an attacker. You can't trust the client anyway, as #Jan puts it in the comments above. Also, everything you do on the JavaScript end can be eavesdropped and manipulated by the client - that's why you can't do a password check in JavaScript, for example. So, the environment JavaScript operates in is fundamentally insecure, anyway.
Security comes into play when the server accepts and uses the data. You need to have all necessary protections in place so the data can't harm your server - for example, remove any SQL injections by using escaping or prepared statements, deal properly with invalid input characters, etc.
Two exceptions to the rule come to mind:
If you are on a SSL (https://) connection, make sure your JavaScript sends the data that way too
Sending the browser to a new location with sensitive GET parameters:
http://www.domain.com/newpage?username=pekka&password=superman85069
is less secure than POSTing a form, because the URL may be cached.
I have built a small app using javascript. I am using javascript for form validation and i am wondering if by using the "no script" tag if this will protect me against people passing non-clean data into my mysql db? I will deny access to the application to anyone who has it turned off. Is this a secure method or do i have to also do php form validation on top of the js validation?
If not, can someone advise me on what is the best way to ensure that the data submitted to my db is not harmful and clean. Id like to do this using javascipt if possible and not layer it with php but if i have to i will as long as my app is secure.
I know i must do some php cleaning such as htmlentities but want to avoid doing form validation with php.
Thanks.
No, you can never trust the client-side to validate. You must always validate server-side. Client-side validation can improve the user experience, but it gives no security benefit.
As a general rule, you never want to rely on client-side code (javascript in this case) to validate data. The client has full control over anything you would put in javascript, and so it would be pretty easy to bypass. Always validate on the server where you have full control of what is happening.
No, you always need to do serverside validation. You can alter JS even when it's turned on (in Chrome for example, you can just pause script loading, edit the JS then run it), therefore it wouldn't even matter if it's on or not.
This is a good starting point: http://net.tutsplus.com/tutorials/html-css-techniques/build-a-neat-html5-powered-contact-form/ (towards the bottom is the validation examples)
Javascript protection is just "visual". Anyone can bypass it and insert any data he/she wants.
You should always validate user-submitted data server-side.
Basically you can start with mysql_real_escape_string() for preventing mysql injection, and do some tag stripping if you are going to display the inputted data back.
I'm developing a website where people will be able to register and access different data via Ajax (powered by jQuery). This is all simple and i shall have no problems doing. the issue is that the data showed by Ajax needs to be secure and not available to be parsed through remote scripts. I can encrypted the data through a AES (in PHP) and decrypt successfully in javascript, but the javascript code will always be visible to everyone (after login). I can use an obfuscator and javascript encryption, but both ways, even mixed, are not secure enough and decryptable. I would prefer avoiding SSL connections, since I am trying to prevent registered users from accessing the information and the SSL connection would only prevent unregistered users from accessing the data.
Registered users will be able to earn money therefore very interested in cheating the code, this is why it has to be bulletproof.
Unfortunately the system needs definitely Ajax (the whole working principle needs to be based on Ajax). The ideal solution would be a way to save the encryption key on a place that can be saved by php and accessed by javascript, but not by users, remote script parsers etc.
Does anyone know a way to create a secure Ajax connection for this purpose?
I really appreciate all your help.
You want something that browsers do not do.
You've asked for: "The ideal solution would be a way to save the encryption key on a place that can be saved by php and accessed by javascript, but not by users, remote script parsers etc."
The design of the web browser and javascript engine in the browser is such that any Javascript that the web browser can execute can be seen by a human who wants to look at it, steal it, borrow it, whatever. Period. There is NO such place that can be accessed by Javascript, but not by users or remote script parsers. You will have to rethink how your app works if this is a problem. Most likely, you need to keep the secret stuff on the server and do more work on the server and less work on the client in order to protect what you want to protect. If you think about it, a browser is just a remote script parser so if you prevent remote script parsing, you prevent a browser. If you allow a browser, you allow a remote script parser.
You can obfuscate your Javascript to your heart's content if you want. That will make it a little more work for a human to understand and do something useful with it, but it will only be an additional obstacle that any determined and competent person can defeat if they really want to. If this secrecy is really important to you, then you need to rethink the design of the app so that secret information is not required in the browser and the browser just works as a display and interaction engine.
Just so I'm clear here. Any code that can be executed by a browser must, by definition, be something that any user or any tool can download and inspect. You can use SSL to protect data from snoopers in transport, but it ultimately has to be readable as Javascript for the browser to be able to execute it.
You can't do exactly what you want. It's like a cheat-proof game design. You CAN make it HARDER, even MORE hard, but NOT 100% secure. You've got to solve the problem froma different approach, like, whatever that is, examine the actions at server-side (e.g. in a stateful manner) and try to detect any non-human behavior. But it's only a matter of someone creating a realistic bot that mimicks the behavior of humans. Encryption is used for preventing 3rd parties -- other than the server and the client -- from eavesdropping/capturing data, NOT for the client. I'm not saying give up on the whole thing, but try a different approach to secure the system. I want to help more, but don't know what exactly you are trying to achieve.
authentication is the only ways to do it.
Just get your users to authenticate (login) and send them the random seed and salt you've used to encrypt their data.
Without the seed/salt, even though a malicious user can decrypt your data it will still be garbage.
If you want javascript to use a piece of data then clients use that data.
If you don't want data to be re-used set up a server-side system where each chunk of data is only valid once.
Proper authentication should solve all these problems.
I want the users to be able to see the data only when Ajax displays them
Then load the data when ajax get's it and not before. Or only partially load data and off-load any sensitive work to the server.
i think the best practice is to make your code (production code) too mush complex to read and edit
you should rename all your variable with letters [a-z] you should not declare ny function always use function(){} inside of another to make it more logical complex this way
the client can still see the code but has nothing to do with it
EDIT: I realize now it's a terrible advice
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.