I have a webpage, let's say that the page is called: http://www.mypage.this/
In my page users can create their own HTML pages and access them through www . mypage . this / (creator's_username) / (project_name) . For instance, if my username is "USR" and my project is called "PROJECT" then the link is http://www.mypage.this/USR/PROJECT .
But there's a security problem...
I store people's login tokens as cookies. And what if some user's script has a function which reads the cookie and sends it to someone else?
They can get access to someone else's account. The token has to be saved as a cookie, because I need to verify the user in multiple pages. What should I do to prevent the user created scripts reading the tokens, yet still allow my pages to read the token?
Thank you in advance
*The tokens are of course regenerated every once in a while
To clear misunderstanding, I am NOT storing passwords in the user's side. I am storing a login cookie - a randomly generated string, re-generated on every login. And I store that on the user's side.
If you have to verify users in multiple pages, you should store login information in the session, not in the cookies. This way everything stays on your server, and only you can access it.
Cookies are made so that you can store information even when the user disconnect, leave the browser or anything else.
Storing login information in cookies is generally a bad idea, as it's not really secure.
Oooh. You really don't want your users to be able to create pages that run scripts in other browsers. That creates a risk of cross site scripting vulnerabilities (like that one you've mentioned here). Your safest bet is to start with blocking all SCRIPT tags. Then there are probably other things to block as well. This is something worth spending time reading about:
https://en.wikipedia.org/wiki/Cross-site_scripting
https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)
Related
First off, Thanks in advance to anyone who resolves/helps to resolve this problem. And sorry if this is a duplicate(I couldn't find it anywhere, so posted a new question).
So the main issue is I want my webpage to display an alert message, subsequently from when a user visits the page for 2nd time onwards, so I thought IP logging using cookies would be the most unique thing to do, please do suggest if there's a better thing to use.
Browsing till now, did not get me a way to log IP in cookies. Also, the solutions I found were somewhat similar but they were in PHP, which, I'm not good at.
I would prefer using JavaScript as opposed to jQuery, but all and any help is appreciated.
First off before I give different ways of identify repeated visit and display a message after 1st visit.
I would recommend not using the IP address because there could be multiple machines behind the NAT routers sharing the one IP address, there will also be a the problem of mobiles always changing their IP address because they will also be connecting to different networks.
There is multiple ways of doing this:
I would recommend using either Option 3 or Option 4 so that there is nothing stored on the users machine. It is then much more secure that client side because people can store of JavaScript on their browsers.
Option 1:
You could have a client side local storage by using the HTML5 Web Storage.
HTML5 Web Storage
Before HTML5, application data had to be stored in cookies, included in every server request. Local storage is more secure, and large amounts of data can be stored locally, without affecting website performance.
Unlike cookies, the storage limit is far larger (at least 5MB) and
information is never transferred to the server.
Local storage is per origin (per domain and protocol). All pages, from
one origin, can store and access the same data.
Option 2:
You could go with using a client side cookie, which you would set and remove with JavaScript:
Cookies are data, stored in small text files, on your computer.
When a web server has sent a web page to a browser, the connection is
shut down, and the server forgets everything about the user.
Cookies were invented to solve the problem "how to remember
information about the user":
When a user visits a web page, his name can be stored in a cookie.
Next time the user visits the page, the cookie "remembers" his name.
Cookies are saved in name-value pairs like:
username=John
I've actually done an example of this few days ago.
COOKIE EXAMPLE
Option 3:
You could have a session, which is a good way of checking if you are having users logging into your website/application:
PHP Sessions
A session is a way to store information (in variables) to be used across multiple pages.
Unlike a cookie, the information is not stored on the users computer.
When you work with an application, you open it, do some changes, and
then you close it. This is much like a Session. The computer knows who
you are. It knows when you start the application and when you end. But
on the internet there is one problem: the web server does not know who
you are or what you do, because the HTTP address doesn't maintain
state.
Session variables solve this problem by storing user information to be
used across multiple pages (e.g. username, favorite color, etc). By
default, session variables last until the user closes the browser.
So; Session variables hold information about one single user, and are
available to all pages in one application.
Option 4:
You could use server side cookies (this way it's not stored on users machine), this is a good way of identifying a user (visitor):
PHP Cookies
A cookie is often used to identify a user.
A cookie is often used to identify a user. A cookie is a small file
that the server embeds on the user's computer. Each time the same
computer requests a page with a browser, it will send the cookie too.
With PHP, you can both create and retrieve cookie values.
Is it possible to access cookies from an email? My fear is that one can for instance steal facebook login cookies simply by sending an email.
I know it's possible to redirect a user to an url without him to be aware of it. For instance, I used to display a 1x1 gif to redirect the user to a url (I used that to make email opening stats). What if on the target url I create a malicious js script: will I be able to access the user's cookies?
Or to put it differently, if there is a link in the email and the user clicks the link, is the target website able to access user's cookies?
I read this; does anyone have more details on the subject?
#user3345621
Thanks for your answer, it seems correct to me.
But to take on the facebook example again, I have a couple more questions:
I may be wrong, but I think the cookie encryption does not help in this case.
The cookie encryption will help to hide the password in case for instance I access
your local machine and look in the cookies directly.
However, if I steel the encrypted cookie, I will be able to use them,
and let facebook do the uncryption work.
So in other words, I think it does not matter whether or not cookies are encrypted,
as long as the application (facebook in this example) will decode them for you.
Now, same remark about the fact that the cookie is recreated.
I think this is a direct consequence of using session_regenerate_id function.
But anyway, my understanding (which may be wrong) is that even if the cookie is recreated,
if the hacker send you a malicious email, he will get the newest version of the cookies
anyway since in the technique I'm describing, you're redirected to a malicious website,
so that website, when opening would have access to the current cookies (if possible).
?
I might be incorrect, since I'm fairly new to application security.
Here goes my best shot, concerning cookies now:
Cookies are domain specific (FACT), when you have a facebook cookie storing your user ID and your email (perhaps?) only the facebook domain has access to that cookie. Also, in most cases, the information in your cookie, especially in enterprise systems such as facebook, is encrypted, in other cases a hash is used to mask the information (Sort of fact).
So let's take facebook as an example, since they use a strong encryption format (FACT). If for instance you were able to get hold of a users facebook cookie, you would need to de-crypt the information to start off with, for it to be of any use to you. By that time a new cookie would have been generated (darn facebook adddicts).
Onto the security issue, if by some means you were able to get hold of a users cookie that does NOT belong to your domain, it would be a hack (do'h!), and you would need to check for any browser (Yes you should be exploiting the browser), that has such an exploit, or look for one yourself..
So here they are:
Browser Exploit, hack a specific browser.
De-crypt (or de-hash) the cookie, if it's encrypted.
And do this all be for the cookie has expired.
And the world is yours.
I tried to send me an email with the following image:
<img src="http://localwebsite/js.php" />
On my local machine, I created a page at this url:
http://localwebsite/js.php
Which would alert("something") using javascript.
Sending the email to myself,
I expected that the mail client would open a web browser page and open the js popup,
but that's not the case at all.
What happened is that since it's not really an image,
my mail client (using mail on mac) did display a blue square exclamation mark,
indicating that he could not display that image.
Even if I click on "load images".
Then nothing more happens:
I presume the mail client goes to the url and tries to display the expected image in the message,
but since there is no image, nothing changes.
The url wasn't open in the browser at all, everything was done in the background.
Reading more about javascript in emails, it seems that generally, javascript is not interpreted at all
in emails.
I tested that too: sending an email containing:
<script type="application/javascript">alert("pou")</script>
Mail (mac) does not execute the script.
So to answer the question,
I believe that the only thing a hacker can do with mail is:
sending a link, then if you click on that link, anything can happen
create an image that he can use to track whether or not you've opened the mail
So if you're cautious enough, mail are'nt a big threat.
I was paranoid…
I'd like to securely save a user's credentials to related web sites and automatically log them into those sites when they log onto ours. I understand there are some security implications to this, so I'd like others' feedback and see what has been successful for others in the past.
What technique have you used to auto-log the users in? I'd prefer not to have to duplicate the HTML form and submit it through javascript. This seems error-prone if the form ever changes. I tried putting the login form inside an iframe, but it seems like the owners of the site are able to block this (see attached screenshot). Do you know how they do this?
Secondly, what was your approach to save the credentials so that they were "safe".
...Peter
I would suggest using cookies to save a session certificate to the users machine. A good value for such a cookie would be;
userid, timestamp, hash(userid . timestamp . global_secret)
The value of global_secret needs to be very long (40 characters or so), to avoid people cracking the hash, as doing so would allow them to create their own credentials with other peoples user ids!
The 'other sites' would check for this cookie, calculate the hash using the cleartext values of userid, timestamp and the global_secret (which all sites know), check it against the hash supplied, if they match, then this is a valid certificate.
You would then need to check the timestamp and decide if this was a 'new' enough certificate to allow access.
This is the standard method.
Do not do this. Read the terms of services for each site (ie facebook):
https://www.facebook.com/terms.php?ref=pf
(3.2) You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our permission.
(3.5) You will not solicit login information or access an account belonging to someone else.
(4.8) You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
You put yourself and the user at risk.
These sites have an API for a reason, so I suggest you looking using those as a more "legal" approach.
So if you're trying to retrieve a facebook user's information, create an app, have them authorize your app, then retrieve the information through facebook's api (example). You can also post to their wall with this method.
https://developers.facebook.com/
https://dev.twitter.com/
https://developers.google.com/
The common method to auto login a user is to set an cookie with an random string. It have to be that the random string isn't guessable. At the server you check the cookie and if it matches then you login the user. But if your site isn't completely served with https everyone who can listen to the traffic can pretend to be the user. To increase the security a little bit you could implement that a random string is only valid for a view days and then the user has to login again and a new random string is generated. So if someone steals the cookie-id the attacker has only for a certain time access to the account.
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.
Just want to get input from people who know. I was considering CSRF vulnerabilities, and the seemingly the most popular method I know to fight against it. That method is to create a token in the returned html and adding a cookie with the same value. So if a script tries to do a post they would have to guess the token thats embedded in the web page for it to be successful.
But if they're targeting a specific website why can't they just use a script that
Calls a get on the page (the cookie will be returned even though the script can't access it)
Parses the html and gets the token
Calls a post with that token in it (the cookie that came back will be sent back)
They've successfully submitted a form without the users knowledge
The script doesn't need to know the contents of the cookie, it's just using the fact that cookies get sent back and forth all the time.
What am I missing here? Is this not possible? I think this is pretty scary if you think about it.
Below this line is not required reading to answer the question :)
This vulnerability banks on the fact that authentication is done based on cookies, which I think is the main way authentication is currently occurring.
Another solution I can think of is making authentication be on the page level. So
when they log in the returned html will have that token in it. every link that they click contains that token so when the web server gets a request it has a way to identify the user/session. The problem with it is that if they use any navigation other than that they will be 'unauthenticated'(e.g. type in a url) , also it doesn't look nice in the url because it would probably look something like this:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
But I do understand that if safety is more important, then a pretty URL is second place.
I don't know everything about cookies but what if user agents were a little more careful with their cookies?
For example, what if the cookies sent depended on the tab? We all surf using tabs by now, right? so what if the scope of the cookie was the tab? so if i have my banking site open on tab 1 and i'm surfing on tab 2, any scripts calling gets/posts on
tab 2 will only send the cookies accrued in tab 2.
Or what if cookies were stored / domain. So while I'm on example.com any cookies that come back go into the example.com cookie collection. and then when i'm on www.mybankingsite.com all the cookies get put into the mybankingsite.com collection. So if I go to example.com and it runs a script that calls a get/post the user agent will only send example.com cookies. This is different than sending the cookies of the requested domain. E.g. if a script calls a get of mybankingsite.com within a web page of example.com the user agent will not send the mybankingsite.com cookies.
I know i have no control over what user agents do, but I'm just exploring possibilities
So I think the problem here becomes the attacker's attempt to get the page's contents. To get the authenticated user's page, the attacker needs to be able to send a request on their behalf and read the contents. AJAX won't send cross-domain requests, iframes won't let you read the response. I am struggling to think of other ways in which an attacker would get the contents first.
A more likely hack is using clickjacking to have the user just submit the form. This technique doesn't seem too likely. (caveat: it's security, we can always be wrong.)
Does anyone care to share some code on this issue as I just hacked my own site (Not in production) with CSRF. All I had to do was the following
At: www.badguy.com/ write the following html
img src="www.goodguy.com/secure/user/delete/5">
What this does
So the admin goes to to www.badguy.com/ and the the image makes a request to
www.goodguy.com/secure/user/delete/5 from the users browser so the admin unknowingly just deleted a user. If you create a loop your in some trouble. Expect I never delete data just change its status :) but still I don't like the looks of this.
The CSRF token has to be unique per session. If a malicious server requests the same page, they will get a different token. If they try to request the contents of the page via JavaScript on the client's machine, the same-origin policy will prevent them.