I am hoping to create an ajax sign in form, which redirects the user on sign in - this is going to check the username and password in the database, and send a true value to the client.
As such I want to do window.location="http://www.someplace.com/mypage.html";
Is this safe? Is there any way of users disabling javascripts redirects?
The user can always disable anything that is javascript based.
That said, using javascript for redirection is not in itself unsafe, and i don't see an abuse scenario, only a breakage scenario.
All in all it depends how you define safe :)
In addition to Martin good answer, don't forget to protect yourself against SQL injection attacks: user can very easily access your target page by himself and send "fake" AJAX requests with malicious stuff like 1' OR 1=1 as the username or password.
Unlike what you might think, AJAX requests are not totally hidden from the user and can be easily detected and manipulated using simple tools available for anyone.
It's not unsafe, but there are 2 alternatives about redirecting without using JS (or if someone has JS disabled):
1) by adding a meta tag in your head
<meta http-equiv="refresh" content="0;url=http://www.someplace.com/mypage.htm/" />
2) better, by a server side redirect i.e. (php)
<?php
header( 'Location: http://www.someplace.com/mypage.htm' ) ;
?>
Edit: As I replied to #Spudley comment, these are 2 other methods to redirect to a page without JS enabled.. in your case #Ashley Ward I think it's the correct way to redirect a page for an ajax-form :)
P.s. a form should work both in ajax and non-ajax way ;) ..remember what other users correctly said: JS can be disabled
Remember that Javascript is all run in the client browser. The user can see the code, and with the right tools can edit it in-situ.
Therefore nothing is "safe" when you're running in Javascript in the browser. You should always assume that a malicious user can and will modify your ajax calls, tweak your variables and change the flow of your javascript code.
However, as long as you've catered for that by making your server-side code secure (ie preventing SQL injection attacks, etc), then you don't need to worry too much about that. A hacker will be trying to break your site, so there's no need for you to worry about whether things will work for him.
For the purposes of a normal user simply running the code normally, then the answer is Yes: your JS redirect should be perfectly safe. The user can switch off Javascript, but of course the Ajax event wouldn't have worked either if the JS was disabled.
If you've written your ajax code to have a fall-back for non-JS users, then you may want to provide a fall-back for the redirect as well, but in all probability your ajax fall-back would load straight to the redirected page anyway.
Related
Im curious, the pages in question are password protected but it got me thinking. Im experitmenting with the Wymeditor J-Query plugin, it works rather well and deals with XSS scripting attempts by automatically converting angle brackets into html characters etc.
Obviously with direct access a user could disable javascript and then insert any manner of malicious tags into the DB. However i am wondering would it be possible for an automated script to disable javascript if it managed to get buy the password protection, and thus insert malicious scripts to the DB which would then be run when DB information is displayed on another page??
* UPDATE *
I should probably have expanded a bit. I would usually strip_tags() and use prepared statements however for Wymeditor to be of any use to the client then I can't use strip_tags(). I know I could write some code to remove any malicious looking content but im not sure just how much malicious content i would be looking for, im assuming XSS attacks are alot more varied than just < script >do bad stuff< script > type of thing.
Rule #1: never trust user data.
Corollary: anything that comes from the client side is user data, no matter what in-browser measures your page takes (An automated script might not be running JS at all to begin with, or may inject form fields not present on your page).
So, while the JS editor doesn't make the site any less safe, it doesn't provide any additional security either: client-side measures (such as JS input filtering) are for user convenience only and provide exactly zero protection; you need to sanitize user input server-side, regardless of client-side.
You should check your data upon insert into the database ... no client side script can protect you. Wymeditor can make the input easier and can help a lot, it but will not protect you against malicious pieces of codes which some hackers will try to insert. So you have to do a stron server side check.
I've been looking for better ways to secure my site. Many forums and Q/A sites say jquery variables and HTML attributes may be changed by the end user. How do they do this? If they can alter data and elements on a site, can they insert scripts as well?
For instance I have 2 jquery scripts for a home page. The fist is a "member only" script and the second is a "visitor only" script. Can the end user log into my site, copy the "member only" script, log off, and inject the script so it'll run as a visitor?
Yes, it is safe to assume that nothing on the client side is safe. Using tools like Firebug for Firefox or Developer Tools for Chrome, end users are able to manipulate (add, alter, delete):
Your HTML
Your CSS
Your JS
Your HTTP headers (data packets sent to your server)
Cookies
To answer your question directly: if you are solely relying on JavaScript (and most likely cookies) to track user session state and deliver different content to members and guests, then I can say with absolute certainty that other people will circumvent your security, and it would be trivial to do so.
Designing secure applications is not easy, a constant battle, and takes years to fully master. Hacking applications is very easy, fun for the whole family, and can be learned on YouTube in 20 minutes.
Having said all that, hopefully the content you are containing in the JS is not "mission-critical" or "sensitive-data". If it is, I would seriously weigh the costs of hiring a third party developer who is well versed in security to come in and help you out. Because, like I said earlier, creating a truly secure site is not something easily done.
Short Answer: Yes.
Anything on the users computer can be viewed and changed by the user, and any user can write their own scripts to execute on the page.
For example, you will up vote this post automatically if you paste this in your address bar and hit enter from this page:
javascript: $('#answer-7061924 a.vote-up-off').click();
It's not really hacking because you are the end user running the script yourself, only doing actions the end user can normally do. If you allow the end user on your site to perform actions that affect your server in a way they shouldn't be able to, then you have a problem. For example, if I had a way to make that Javascript execute automatically instead of you having to run it yourself from your address bar. Everyone who came to this page would automatically upvote this answer which would be (obviously) undesired behavior.
Firebug and Greasemonkey can be used to replace any javascript: the nature of the Browser as a client is such that the user can basically have it do anything they want. Your specific scenario is definitely possible.
well, if your scripts are public and not protected by a server side than the Hacker can run it in a browser like mozilla.
you should always keep your protected content in a server side scripting and allow access by the session (or some other server side method)
Yes a user can edit scripts however all scripts are compiled on the user's machine meaning that anything they alter will only affect their machine and not any of your other visitors.
However, if you have paid content which you feed using a "members-only" script then it's safest if you use technology on the server to distribute your members-only content rather than rely on the client scripts to secure your content.
Most security problems occur when the client is allowed to interact with the server and modify data on the server.
Here's a good bit on information you can read about XSS: http://en.wikipedia.org/wiki/Cross-site_scripting
To put it very simply:
The web page is just an interface for clients to use your server. It can be altered in all possible ways and anyone can send any kind of data to your server.
For first, you have to check that the user sending that data to your server has privileges to do so. Usually done by checking against server session.
Then you have to check at your server end that you are only taking the data you want, and nothing more or less and that the data is valid by validating it on your server.
For example if there is a mandatory field in some form that user has to fill out, you have to check that the data is actually sent to server because user may just delete the field from the form and send it without.
Other example is that if you are trying to dynamically add data from the form to database, user may just add new field, like "admin", and set it to 1 and send the form. If you then have admin field in database, the user is set as an admin.
The one of the most important things is to remember avoid SQL injection.
There are many tools to use. They are made for web developers to test if their site is safe. Hackbar is one for example.
I would like to use session storage to query user data in the database only once and then simply use JS to retrieve it, so I'm thinking about using session storage. My question is next, is that safe?
Please note:
1. JS can't be inserted to pages with forms (forms only accept alphanumeric values) so it can only come from URL
1.1 Query strings like www.website.com/?q=blablabla are not used in php (php doesn't retrieve any data from url)
1.2 Calling js in url with javascript:script... isn't a big concern since the user can only asccess his own data, not to mention that he can already access it - that's the point of user data
1.3 Is there a third way of a user being redirected to the site via a link that contains JS that will than be able to access session storage? i.e.: somthing like - www.website.com/script...
My guess is that only something like 1.3 would be a threat (in addition to that, am I missing something?) but does that even exist? And if so is there a way to prevent it?
Thanks for your time and replys.
You're essentially relying on two things for session storage security:
The browser limiting access only to the javascript on the page from this domain
javascript that is running on the page to be secure
Now there's not a whole lot you can do about No. 1 because that's the vendor's issue and, not pointing at anyone in particular but, most of them are usually pretty good at this kind of thing.
So you can be fairly sure no other code on any other tab, domain, browser or process is going to be able to see your storage object.
However, No. 2 is more difficult, You'll have to evaluate by yourself how secure your page is to script attacks, there's plenty of documentation out there on best practices but you could go on for days. You really need to judge how sensitive the data is versus how much work and possible loss of features it would be to secure against it.
If it's really sensitive data I'd question why you'd risk storing it client side at all and have access only through HTTPS. But you're site should be secured for most scripting attacks because if 3rd party javascript is running session cookies are up for grabs and therefore your server security is compromised too.
Since the session storage can only be read by JavaScript that is running on your page, I think your question boils down to "How can JavaScript be excuted/inserted into my page?" There are two attack methods: XSS, meaning some way to inject JavaScript into your page through posting data to your site. If this data is not filtered, it may insert script tags or JavaScript events into your HTML. There are many ways to do this and to protect against it, so I can't be more specific.
A lesser threat would be to trick the site into displaying or changing information through specially crafted links that call specific actions on your page. This technique is called CSRF. Example: Someone crafts a link to the "change email" page and tricks a user who is logged into clicking this link, this changing the email info in the session storage.
If your application is public, anyone can open the session storage in his browser and look up the names of the keys. So unless they are randomized obscurity offers no protection here.
I want to block non-browser clients from accessing certain pages / successfully making a request.
The website content is served to authenticated users. What happens is that our user gives his credentials to our website to 3rd party - it can be another website or a mobile application - that performs requests on his behalf.
Say there is a form that the user fills out and sends a message. Can I protect this form so that the server processing the submission can tell whether the user has submitted it directly from the browser or not?
I don't want to use CAPTCHA for usability reasons. Can I do it with some javascript?
You can raise the bar using javascript, but anything a browser does, an automated system can do. At the very worst, they could automate a browser, but there will almost certainly be some easier way to simulate the operation.
In any case they can record the requests that the browser sends using a proxy, and work out whatever tricks you have the javascript do.
In terms of what springs to mind (to raise the bar) (using javascript):
Change the location that the submit goes to.
Change field names around at submit time.
Hide fields that look like should be filled in.
Encrypt/obfuscate form contents at submit time.
Change GET to POST.
Another usability problem is that anybody who has javascript disabled won't be able to use the service at all. That might impact usability more than a CAPTCHA.
There is no reliable way to detect the HTTP agent - you will break the form for some browsers in any case - unless you can force users in to using a very limited set of browsers (but this can be spoofed again).
IMO, trying to limit the software that can be used to access the form, you should make sure that there is a real human controlling that software. Unfortunately there is no better way than captchas for doing this, unless all customer have access to biometric scanners.
There is only one way to do this, analyzing vendor string looking for browsers admitted, but if someone fakes the vendor string theres no way to keep away from submissions.
To know if a navigator is mozilla based with javascript :
var isMoz = window.navigator.userAgent.match(/^Mozilla/)?true:false;
with php you could try native function get_browser
I'm working on a website for my county's fair. I want to allow my visitors to be able to ask me questions by inputing their name, email, and comment in a form like this one:
http://lincolnfair.net/images/feedback.JPG
So I guess my real question is how can I send an email (using JavaScript/JQuery) to myself with all these fields as the main body of the email.
You should use a server-side script (e.g. PHP, Python, Perl, etc.). With pure HTML and JavaScript, you can use a mailto form, but this will be very unreliable.
I will suggest uservoice.com , it can integrate with your site nicely, a much more powerful user feedback system, without spending time to code the feedback system yourself
As others have indicated, this is a typical task that can be solved easily using a server-side language. Javascript and jQuery aren't the right tool for this particular problem. To point you in the right direction, use method="post" for your form, and you can access users' submission in a PHP file by examining the $_POST variable. If a <input> element in your form has name="email" in your email, you can access that variable in PHP as $_POST['email']. If you're interested in a PHP solution, look at the documentation for the mail() function.
Jukka has a good guide on How to write HTML forms. It should give you everything you need to produce something functional.
You need a server side component, nothing client side will be a reasonable substitute for that. JavaScript won't help for a form as simple as the one you describe.
The most reliable way will be to use a server side script in your preferred language. The specifics of how to do this are probably outside the scope of this question and would depend upon your language of choice.
Your other option is to set the action of the form as a mailto: which will use the visitors preferred email client to send the email. This will work but is really bad and relies on the viewer having an email client installed and configured.
you can find out more information about the mailto option at http://www.chami.com/tips/internet/010597I.html
Another good option would be a third party site such as www.wufoo.com which handle all of the email business server side for you on their own servers. I believe Wufoo even allow you to embed their forms within your own site.
If you want it to be available on every page, you might want to consider using jQuery and the UI Dialog plugin. You could set it up so that the default feedback is a mailto which gets replaced using javascript with a link that brings up a jQuery Dialog containing the fields you want to collect. This could be submitted back to your server via AJAX and delivered to you via email from the server.
EDIT: Since you've edited your question to indicate a server-side only solution, the above seems somewhat out of context. With others, I would agree that using some client-side code to actually send the email is the way to go (as alluded to above). I think it's preferable to use your own server for this, but I'm sure that you can find many "form to email" services. I would avoid these, unless you want your email addresses harvested for use in SPAM. You might also be able to use a signed applet or ActiveX control for this, again I would not go down that route. As indicated above, I would let the browser handle the interface, but my server handle the sending of the email.
I am not sure i understand your question completely, but if all you want to do is conduct a survey over email, i don't think you need to use jQuery or HTML.
A very simple way to do it is to use the 'Forms' feature in Google Docs.