I am developing a web application in Django. Vital to this application's core functionality is taking user generated JavaScript and submitting it through a form into a MySQL database. This JavaScript code will then be served into webpages that anyone will be able to see, where it performs some calculations behind-the-scenes. I know this is very dangerous because of XSS and perhaps other reasons, but is there any way that I can do this safely? Has anyone ever done this or seen it work successfully?
Also, the most important thing that the JavaScript needs to do is math. Maybe there's a scripting language that doesn't have all of the power of JavaScript that can still run in the browser? Then I could sanitize the input making sure it is that math language and nothing else.
Related
I am creating a website which until now is pure PHP. I was thinking that since very few people do not have JavaScript enabled (which I wonder why!) maybe I should create my website as a fully PHP site without any AJAX. Am I thinking wrong?
Just to be sure, if I implement some AJAX would it increase the risk of my site getting breached?
Should I be even worried about this and start using AJAX?
AJAX itself will not increase or decrease the security of your site, at least if its implementation is elaborate. The client (browser) will have turned JavaScript on or off. If it is turned on, there may be more insecurities on the client side, but this won't affect your server and hence your site.
Nevertheless, you should of course implement your AJAX entry points securely (this server side files that are accessed by AJAX requests). Two of the most important rules of thumb you should keep in mind are:
Treat every user input (whether coming in via AJAX or not) as potentially "evil" and therefore validate it thoroughly and use database escaping, ... Do NOT rely on client-side validation only!
A good website should offer all the possibilities accessible with javascript enabled also without it. Surely, this is not always possible, but one should try it at least.
I would suggest using a framework (depending on what background technology you are using, like PHP, Java, Perl) supporting AJAX, which will make the whole thing much easier for you. Also, you should maybe search for something like "securing AJAX applications" to get more detailed information on the topic.
Ajax is not inherently secure or insecure.
It does however open up 'opportunities' for insecure code. A mistake I commonly see is as follows:
The user is authenticated in code-behind when the page is loaded
A user id or other credentials are rendered out and picked up by JavaScript
These (totally unauthenticated) credentials are sent back over the wire by Ajax and not checked server side. Very easily hacked even with a simple tool like Fiddler!
You must apply the same level of security to your web methods/web API as you would elsewhere in your site. If you do, Ajax should be no more or less secure than 'regular' web pages. Things to watch out for include:
Proper authentication and authorisation checks in your web services or API
Anti-SQL injection measures
HTTPS if transmitting personal or sensitive data
Ajax makes websites more responsive and is pervasive across the modern web. Take care with security, and degrade gracefully for non-JS-enabled visitors if you expect a significant number of visitors to have JavaScript turned off or if any lost visitor is not acceptable to you, and you should have nothing to fear.
I am creating a website which until now is pure PHP. I was thinking
that since very few people do not have JavaScript enabled (which I
wonder why!) maybe I should create my website as a fully PHP site
without any AJAX. Am I thinking wrong?
I would say most people do have JavaScript enabled. Probably 2% at most have it disabled according to this post from 2012.
Just to be sure, if I implement some AJAX would it increase the risk
of my site getting breached?
Yes, technically it does. More code = more chance of bugs, and security bugs will be a subset of these.
You will also be increasing the attack surface of your application, as you will be generally be implementing more server-side handlers for user actions to be executed asynchronously.
There is also more chance of client side bugs being prevalent such as XSS (particularly more chance of DOM based XSS bugs sneaking in there).
Should I be even worried about this and start using AJAX?
You should be "rightfully concerned" rather than worried. The increased risk is considered acceptable by most sites, even high security systems such as banking applications. If implemented correctly it is possible for your site to remain "just as secure" as it was without AJAX.
As with anything web-based, pay particular attention to the OWASP Top 10 and follow secure coding practices to minimise the risks. It is always advisable to get a security assessment carried out by an external company to pickup anything you've missed, although this can be expensive.
I use some jquery and JS functions to validate forms and to check for example if that field is empty or password is less than 6 characters, and stuff like that, and I noticed that if someone disabled JS, then these functions would be useless, and no more protection of forms, which can be better made using PHP, so should I avoid them now because this could cause an insult to my website ?
JavaScript is very useful for improving user-interaction, along with reducing the number of requests made on the server; but, as you've pointed out, it can be disabled. To answer your question: No, I wouldn't recommend avoiding the use of JavaScript, but the key is not to rely on it for critical actions, such as validation. You'll want to implement the validation on both the client (JavaScript) and server (PHP) sides. This will ensure that there is no way for the user to completely disable the validation.
In short:
JavaScript = Good
JavaScript Validation = Nice for the user, but not reliable
Server Side Validation = Essential
Side note:
With regards to relying on JavaScript for the overall user interaction, as other answers have suggested, use JavaScript to enhance the overall experience, but don't rely on the user having it turned on. I would recommend a bit of bed time reading of Progressive Enhancement, it's the approach of making something better, with being reliant on it, and can be applied to more than just JavaScript (CSS3 etc).
You should use javascript and jQuery to enhance the functionality of your site. If someone has javascript turned off you should ensure that the site still works, and they can access all areas - even though there may be some things they cannot see, such as transitions and effects.
With regard to validation, you should ALWAYS validate server side. Client side validation is optional, but a very nice feature to improve the user experience for your visitors.
I don't mean this as a complaint, more of an observation.
Web developers often grab Javascript libraries as the latest shiny toys with no thought for the consequences. As a Data Governance person, I'm regularly the bringer of bad news, when we do audits on the data collected, and find users who get past the Javascript validation.
"Go back and start again".
Javascript libraries are great for the presentation of data, but should and must not be relied on for data validation and the integrity of user profiles.
A validation should always happen at
Client Side - using javascript to enhance the user experience.
Server Side - using the preferred server side programming language for security reasons
Service Side - if you are following SOA / Web API as part of defensive programming practice. This can also be at the DB level along with Service layer.
You should not avoid using JS and jQuery in your website, but you should avoid using them for validation purposes or business-logic purposes. These should be done in the back-end of the website, not in the UI level.
You shouldn't really avoid them. What you should do is to implement both client and server validation. Don't rely just on client validation, for the reasons you just mentioned. You should always validate the data when it arrives to server.
Adding client-side validation gives your pages dynamic look and feel. A user does not have to wait for the form to go to server and in case of an error to return back. It is automatically verified without postback.
As I said above, don't rely upon client side validation. Always implement server-side validation also.
Remember my friend, Java script is client side scripting. its purpose to validate form at client side itself so we can avoid overhead...You must use java script at client side. because PHp is server side language. It will take time to reply.
Ha, Server Side validations are equally important. if you want to do that, then you can use server side language. You can check comment below to my post by halfer. Server side validations are important for security and many more purposes.
That is different thing that somebody disabled js. You can check for the same and give proper message to enable.
I'm looking into using Backbone.js and node.js to write a small web app. Sharing code between the client and sever is attractive.
I can't figure out how clients without JS (and search engines) should interact with the site. How should form validations and rendering work with no client-side JavaScript work?
Of course, I'd like to do this without code duplication. Seems to me the point of Backbone.js and other server-side js is that you can have the same form validations and template/view generation on the server AND client.
If you have your view coded with javascript, search engines are buggered as they conform to a more traditional web (one url, one state, one page) and don't understand javascript.
You need to use graceful up-gradation if you want to provide a rich experience and support search engines.
With graceful up-gradation, you code your website with no client side javascript, get it all working nice a nifty. Then you use javascript to upgrade the experience. In most cases this is actually easier, as the upgrade process can be automated. See https://github.com/browserstate/ajaxify
Validating the form data on the client side is a good practice because it saves a user from potentially having to re-enter what was written if it does not validate on the server. Validating on the client side does not remove the need to validate on the server, as your question helps point out, because there is no guarantee JavaScript will be running or even that the form used is the one on your server.
I am currently working on securing my javascript code. I am using Asp.net 4.0 When i was checking my mail on gmail I just right clicked & selected view source & It just showed me <html><body></body></html> . Can i implement this type of security in my application or any other best security feature that will hide/encrypt my javascript code
No, short of obfuscating it, there's nothing you can do to prevent somebody from seeing your code. Even then, obfuscating it only makes it more difficult to interpret, not impossible. Javascript is interpreted by the client's browser. The only way for it to be executed is for the source code to be available to the browser at runtime. In order to "encrypt" it, you would need to then provide the encryption key to the browser which would defeat the purpose of the encryption all together.
I was looking into GWT. It seems nice, but our software have the must work without JS requirement. Is it possible?
No, it isn't. GWT provides a windowing toolkit that is specifically designed to run on the client, not on the server. Degraded (e.g. non-javascript) code would need to deliver complete HTML to the browser, which GWT simply does not do. It compiles your java code to a javascript file that is delivered to the client and builds the UI by DOM-manipulation on the client. Then there's some code to talk back to the server, some implicit, some written by you yourself. This model does not lend itself well to degrading gracefully.
The only way to degrade somewhat gracefully is to provide a second, non-javascript UI or use another toolkit that doesn't render the frontend on the client but delivers HTML. Sorry.
You could degrade gracefully by creating an html structure that is just 'good enough' (with form posts, linked menus, etc) and then have GWT attach to each part of that structure, augmenting its behavior. For example, make an HTML drop down dynamic, replace a link to another page with a component that opens a lightbox, or replace a link to another page with an XML http request to do the same thing (e.g. cast a vote).
I've done this a number of times for clients.
It's the opposite way that most GWT gets developed, but it can work.
I was looking at this issue myself when designing my website. GWT isn't really any better than just writing Javascript files in that their syntax is almost identical. The true benefit comes when you share client and server libraries. Hopefully you've resolved this issue in the last two years, but at any rate here are a couple examples that you may find useful.
Creating Gmail: With GWT, you can create an EmailFormatter in a shared package that does the email listing markup so that your server doesn't have to. You could then add support for legacy browsers ("older version") by using the same EmailFormatter class on the server side.
Form verification: While is is absolutely necessary from a security perspective to validate user input server side, it is more convenient for most users to have Javascript check a form before it is submitted. You can use the same Java code with GWT to do this.