I got some of my nifty rails apps working, and its all jiffy and peaceful. I want to secure one tiny part that just feels wrong doing the way it is now - my sign-in procedure, where I use the form_tag with the remote option to send the content of a text and password field for obvious reasons using POST.
Sending a password just plain over HTTP makes me feel dirty. From where I can see, I have the following options:
learn to live with it and hope for the best
learn something awesome to have my controller doing magic through a rails-helper-i-dunno-about trick
build a separate app that runs on HTTPS and make life a living hell by going back to square one.
use JavaScript encryption
Somehow I think my best option is 4 - JavaScript encryption.
However, if the user types in his/her password and it gets encrypted with a part that is server-generated, it should be secure (in relation of solving the problem of sending it in plain text over HTTP) and solve my problem I guess. But on the rails side, to get that to work is to keep (yes, i have many things to cover, still) plain passwords in my database.
I need some help here - some pointers.
Why you should not use option 4: The risk of implementing something wrongly and putting your users at risk is much higher than when using something which already exists.
What you should do instead: Secure your users data by transferring it via https. Put
config.force_ssl = true
into config/environment/production.rb and you are ready to go. (Well and tell the webserver where appropriate certificates are…)
Related
For our web application, we want the client to be as thick as possible, and keep our server as thin as possible. The idea is to give the client all the necessary data, let the user interact with that data in a snappy Javascript application (currently GWT, but we are considering moving to Angular or Backbone). We would like to make the server completely stateless, which improves scalability and memory usage.
A fundamental problem of course is that there is some data a user is not allowed to alter. For example, when doing a password reset procedure, the user cannot change his username, because then he could alter somebody elses password. There is also a boolean that indicates if the user has passed the captcha, we cannot allow him to set that to true. And many other examples can be thought of.
The solution we thought of is the following: Together with these strings that a user cannot touch (we call them the priviledged information), we also add a signature. This is simply the concatenation of the priviledeg info, HMAC signed on the server with an AES key. When the data from the client returns we concatenate and sign the info again, and if the signatures are identical, we know that the client has not touched our info.
My questions: Does anybody see any weaknesses in this scheme, and can anybody point to resources (books, blogs) where more info about this subject can be found?
For anyone finding this question after several years: The thing I suggested was basically the same as Json Web Tokens (https://en.wikipedia.org/wiki/JSON_Web_Token). The idea I suggested was correct, but of course you should use established libraries instead of rolling your own.
In my app, I will provide my client a javascript plugin, which will collect some HTML data and send to my server. I wonder what's the best way to identify my client. Say someone copied the javascript and put into his website. A similar case is the live chat plugin.
Really your questions it is not very clear to me. I am monitoring it from the beginning, so as no one answers I can say the following:
1.- If your javascript plugin is to plug in websites, as a jquery plugin, then you don't be sure about nothing because the code can easily be modified to remove any security procedure.
2.- If your javascript plugin is to plug in browsers, as a FF addon. Well, indeed can be modified too, but in the most of cases you can track simply with cookies or a login procedure.
Said that I think that if the case is the first (plug in websites) you could identify the websites asking for a authentication token stored in the server's website (requested by AJAX) and add it to the HTML data that is send to your server.
Hopefully you can understand my Emglizch :) and do not say pure garbage.
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 have a quetion which may be simple/dumb or not :). In other words I have no idea if is fair enough or a completely foolish idea. Just some free thoughts.
What if I make my login via JavaScript with pass in it (yes I know), but pass will be hased by Secure Hash Algorithm. For instance:
I generate a pass with SHA which looks like
var = 0xc1059ed8... //etc
and paste into the code. There will be also two functions. One will compare two values (given by me with user's) and second will generate sha form user's input.
Is this could be safe theoritically or this is a horrible pattern and stupid idea? Can JS handle it?
EDIT: I didn't mean serious autentication like banking one. Just when I have my pics and want only to a few ppl to watch them and 99,9% of ppl on earth can't watch them :)
thx for responses
Sorry, no dice :) Secure authentication is not possible with client-side Javascript alone, because a positive authentication result could be faked. You will always need a server-side instance to authenticate against.
The common answer is that 'no, you can't do client side authentication' and for conventional scenarios that is correct, but I can think of at least two ways to make it work:
Use the SHA password hash to redirect to a static HTML page (0xc1059ed8...html). As long as the virtual directory doesn't allow file listing, no one will be able to guess the name of the file you want to protect. This gets clumsy really fast though.
Use an implementation of an encryption algorithm (AES, etc) in Javascript to decrypt a block of text that makes up the actual content of your page. Really only practical for one highly valuable page though.
Server side authentication is really the best, but it is incorrect to say that client side can't be done.
You cannot secure your site with Javascript alone. You will need some way to authenticate requests on the server.
Because all your javascript code is plainly visible to all consumers of your site. All a potential attacker would need to do is view souce of your website and they can bypass the password checking bit of your javascript and view the content behind it.
You need to have security implemented on the server-side, period the end. ASP.NET has a built-in way to do this called "Forms Authentication." Or you could use Session variables in a php script.
Your JS source will be visible anyway and anyone can fake it easily. You have to do a server side validation
Since the hash will reside on the user's computer (in the browser), i'd say it's a terrible idea. It will be easy to manipulate it.
You can use such a pattern to hide the password over a plaintext link and avoid https to login , but not as it stands.
The problem is that an attacker can steal the hashed password and use that to login to the server, and she does not need the real password.
This can be thwarted by a challenge response where the server sends with the page a "salt" : a big random number which is jumbled up with the password and then hashed, so the response is always different.
Unfortunately this has the effect that the server now needs to have plaintext passwords, which is a bad idea (ok, there are some tricks around this). So you might have to end up with a sending a salt, hashing your password, jumbling the hash with the salt by hashing it again and sending that to the server. The server hashes the stored hash of the password from the user db with the salt and compares both.
With security things get complicated real quickly and in complicated things opportunities lurk for the bad guys. A reason more to use well tested patterns, algorithms with a proven track record and libraries which have carefully implemented these.
And in any case it will be the server hwo has final say who can get access.
You'd be better off with no attempt at authentication at all -- at least that way you wouldn't give anybody the dangerous illusion that something involved might be secure.
Assuming you're dealing with a shared-secret situation, authentication is really pretty easy. You use a fairly simple challenge-response algorithm. Basically, the client sends a message to the server saying it wants to log in. The server responds by sending back a random number. The client encrypts that random number with the correct password, and sends it back. The server encrypts the random number itself, and compares the result to what the client sent. If they match, authentication has succeeded -- you've confirmed that the client has the right password.
The advantages of this: first, the password itself is never sent over the wire in any form, so an attacker has virtually no material to use in attempting to discover the password. Second, since the server generates a new random number for every login, an attacker cannot successfully authenticate by re-sending the packets it captured from a previous login.
Nearly any server with any sort of aspirations to security will already have something like this built in. It's purely a question of setting up your client to interact correctly with the form supported by the server(s) you care about.
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.