Using: PHP, Symfony 1.4, Doctrine, sfGuard
I have a site where the majority of pages could be cached as full HTML pages. But there is the traditional 'user account toolbar' that appears at the top right of most sites (shows the logged in username, logout link etc.)
This obviously prevents the page from being fully cached as HTML so I plan on outputting the page as standard HTML and adding in the username etc. after page load, via Javascript.
When the user logs in, I will create an extra cookie storing just the username. Javascript can then check if the cookie exists and create the account toolbar. The username will only be used for display purposes. In order to actually log in the users will have to go through the normal login page, using their password etc.
I've searched for blog posts etc on this but not found much. Can anyone identify any security or other concerns with this?
As long as the user name is only used for display purposes you should be golden. Alternatly you could use an XHR to grab the username from PHP's $_SESSION.
My concerns are that you'd be using the user name to authenticate that user. Or using the user name as a key to access your cache, where by changing the user name would give an attacker access to another's cache.
You should never, ever store anything sensitive in a cookie. To me, that includes usernames.
Related
I am developing a social network and I would like to know if in the profile page of a user I could put the user id stored in database as a parameter in the url or is it a bad idea in terms of security?
I want the url to be bookmarkable. Should I put another thing instead of the user id?
In terms of security there's no problem in putting the user id in a url. For example StackOverflow does it already: https://stackoverflow.com/users/3477044/aliuk
What's important is to verify that the currently authenticated user is allowed to access this url and take actions on its behalf.
most socialnetwork i've been using, use username as url not id, of course it also affects seo, since u have "pretty url".
Security is really depend on how you write your code, say there is a page to edit-profile, if you put on your code something like:
UPDATE .. SET .. WHERE id = $_GET['id']
no question it's dangerous, you should check every user action, like posting/editing profile, etc. who is login, not what's the id on current url
It is secure if you secure your website against sql injection.
But if breach happens all users are vunerable. Only thing that hacker needs to do is find the user profile get his id. Copy output of sql injection. Go to text editor. Press ctrl - f and search for user id.
I have a full website with two contexts for two different languages. The only public page is the landing page of both languages. The rest should be private/protected. This I have achieved with resource groups and limits on the anonymous users.
On the landing page all the menu entries that are protected should be seen by the anonymous user and if clicked a popup with two login-forms should be displayed. These login-form are from other sites and will return if the users has permission or not when they've entered their credentials. And as long as this session exists the user should be able to view all pages if the user was approved of course.
My guess as a non modx- or php- pro is that I should check if a session exists when the landing page is loaded (and all sub-pages). If no user is logged in all links will point to the popup. The user then logs in, sends info to the external server and is redirected to the private/protected landing page if successful. And this is what I can't find any info about, probably because I'm not entirely sure what to look for.
I need one snippet that checks if a valid session exists for the protected pages, if not display the logins.
The other code I would need is something that creates the session for the user if the external login was successful. Should this be a snippet or just a php document on the server. And how can I start a session for the protected pages?
You could do this in two different ways:
Make a user-system that is not connected to Modx. I find this the easies and I've done this several times before. You'll need to make a table for users with usernames and password, and make an object out of it, so you can use xpdo to do the queries. With this system up and running, it would be no problem to include a snippet in every template to make sure the user is indeed logged in. If not, just redirect him to the correct frontpage/landingpage. This will require some coding, but as I said, it works like a charm.
Download the snippet http://modx.com/extras/package/login (by Spittingred, a true legend), and look at the code. I haven't used this Extra before, but I am pretty sure it uses the same user-system as Modx, and therefor you should be able to achieve what you want. I can't give you any more help than "look at the source and figure out how Spittingred did it".
MODX Revolution checks if the user is logged in when trying to access a protected page, but if you would like to check it manually this snippet would do:
if (!$modx->user->hasSessionContext($modx->context->get('key'))) {
$modx->sendUnauthorizedPage(); // redirect to the informative page for non-logged users
}
If you need to check for the user being logged in and display a login popup if not, then using the output modifier with simple user id check may work:
[[+modx.user.id:if=`[[+modx.user.id]]`:eq:=`0`:then=`Not logged in`:else=`logged in`]]
When it goes to the session creation for the users authenticated from outside of MODX site, I would suggest to write a snippet which checks the status from the eternal page and logs user in. This way the session checking will be ommited but still, the functionality goal should be achieved.
I have a members area on my site where if a user is not logged in, they are redirected to the login url with ?redirect=[CURRENT_URL] and they are redirected back to [CURRENT_URL] once they successfully login.
What are the potential security issues with this approach, how to prevent them and what are the alternatives?
e.g. a malicious user can link to my site with a redirect link to another site, would that other site be able to steal my user's login cookie? Is it possible to run arbitrary javascript on my site with this approach?
If current url is not redacted, you can be subject to
XSS (stealing cookies, injecting
scripts)
Response Header Splitting
etc
If you know current URL is a constant and has NO parameters, it's not as risky. As soon as you add parameters or make the url based on user input, trickiness ensues.
A trivial example of XSS:
Say your url can have a query string injected via user input. Then
what stops them from saying
redirectUrl="yoursite.jsp?somevariable="alert('malware')");
or
redirectUrl="yoursite.jsp?somevariable="alert(document.cookies)");
And stealing your cookies or executing other evil java script.
Response splitting is more complicated. Basically if you can inject a CRLF you can do some very whacky things.
Wikipedia has a decent explanation of this vulnerability - there are others you can find by googling for http response splitting.
I've left out the most obvious attack which is if the user can control the url they can go to a site that LOOKS like yours and convince the user to enter credit cards, credentials etc. Eg if you are a bank, and someone can inject
redirectURL="http://myfakebank.com"
and copies your page, gosh, the user will happily say "Sure, I'll reeenter my credentials"
My bookmarklet can be called from any website and basically allows the user to insert a row into his collection from afar - if he is logged in.
Now I want to enable CSRF protection for my site and since a bookmarklet is basically non-forged cross site request, I thought about how I could tell it apart from forged ones.
It's not a high-security environment, but I'm also interested in principle.
I thought I had a way to do it figured out, but then realised that it had problems galore.
Original idea
generate a random key that is included in the bookmarklet-link. The key's hash is saved in the database. The random key allows access ONLY to the privilege of insertion into this collection and can't be used anywhere else.
the bookmarklet loads a longer script from my server, so I could supply a CSRF prevention token this way
require the user to be logged in
Problems
If I have the bookmarklet key, do I need counter-CSRF tokens?
Is there any way that I could protect the bookmarklet key if the user clicks his bookmarklet on a malicious website?
I don't want username and password to be stored in the bookmarklet link, because anybody who has access to the computer would get the password as well then, so I decided on the random key.
but if I store only the hash, I cannot generate the same bookmarklet link twice, so when the user wants a bookmarklet in another browser/computer he tediously has to import the link from the old one or break support for the old one.
but I shouldn't store the cleartext key, because someone who gains access to the database could use this key to insert rows into accounts that don't belong to him.
Possible solution I could ask the user to provide his password anytime he creates the bookmarklet and hash the password many times and put that hash in the URL and put the hash of that hash my database. But of course this opens much worse security holes.
I could do this with something like "Mother's maiden name" instead
I cannot use bcrypt for hashing because of the random salt, right? What hash function would be right? Or would you dismiss the whole idea?
If I leave the bookmarklet key out, a malicious website could simply embed the bookmarklet and extract a valid CSRF token from it, right?
Better ideas? Or can't you have CSR without the F?
Edit, specified use case
One thing I simply didn't think about, is the usage of an iframe as suggested by Sripathi Krishnan.
I had not specified my use case, so yes, an iframe is a valid solution to the aforementioned
problem.
However, actually my bookmarklet at the moment does do some basic interaction with the website at runtime (meaning the form is there already and the user can change his selection in the website DOM which should change the form). I'm ready to dismiss this functionality for my use case, if it turns out, there's no reasonably-secure way to tell apart forged from non-forged cross-site requests - but I'm still interested on a theoretical level.
You can't make cross-site requests without eliminating the forgery part. But for your use case, I don't think you need cross-site requests.
Lets assume your service allows users to bookmark any pages he wishes. The job of the bookmarklet would be to save {url, title} into the database. At the same time, you want to prevent a malicious website automatically saving urls for a user who is logged in.
Here's what I would do to solve this -
Create a page on your domain that has a standard html form with regular CSRF protection. This page takes in the parameters {url, pagetitle}, but will only save this tuple when the user explicitly clicks the "save" button.
The bookmarklet's job is to load the iframe
Once the iframe loads, its a normal same-origin request
This is more or less what Google reader does as part of its bookmarklet. Here is the code for its bookmarklet - notice it doesn't have any tokens
javascript:
var b=document.body;
var GR________bookmarklet_domain='http://www.google.com';
if(b&&!document.xmlVersion) {
void(z=document.createElement('script'));
void(z.src='http://www.google.com/reader/ui/link-bookmarklet.js');
void(b.appendChild(z));
}
else{}
EDIT :
You can still support interactions with the iframe approach. The bookmarklet executes in context of the website, so it has access to the DOM. You can interact however you want with the website. When you are ready to save, open up the Iframe. The iframe will be a sort-of confirmation screen with just one save button.
The trick is to delay creation of the iframe. You only create the iframe when the user is ready to save.
If the bookmarklet is being stored in a web browser then the idea of including a secret key which hashed in the database is a good idea. This will prevent CSRF, although it is not ideal because in a sense this is a session id that doesn't time out. It should be clear that this token is only being used for this bookmarklet action. Despite this limitation it is unlikely that you will experience an attack. Adding HTTPS will make this stronger because it will be harder to spill this token.
If the bookmarklet is originating from a 3rd party site, then there is nothing you can do. This is the definition of CSRF.
I initially designed my site to show a login box at the top of the page if the user was not authenticated (e.g. how reddit.com works).
I encountered a user who was having trouble with their browser's storage of their password because after a password change because their browser had stored their login information at different urls on the website. Even after the user typed correctly the new login information at one url, and the browser updated it, there would be other urls at which the browser had the incorrect login information.
This would also cause problems with sites that have a login box on their main page, and a special login page -- especially if the user front page login box is sent to the login page.
Is this a small enough case not to bother with, or should there only be one url at which a user can login to prevent this problem, especially for less technically-savvy audiences?
There should be one login page that every other page accessible sans login links to. It standardizes the process of logging in and reduces the kind of confusion your user experienced. It conforms to a convention that all the browsers are using with respect to saving passwords as well. Don't really see how you can go wrong that way.
Most sites use a single "sign in" button that takes you to the canonical login page.
If you want a signin box on every page that the browser can remember, consider using an iframe to hold the form.
I believe that if there is any way to use only ONE login location you should try to do it that way.
As you yourself said it's quite hard for browsers to determine what to do with stored passwords for sites with multiple login locations. There are possibly other problems and all of them are solved by having exactly one login location.
If you need to provide login from more places, just use redirection. But getting "in" your system should be done from one single place.
Just have one login page and have the other pages on your site linking to it. It keeps it simple for end users as there is only one page and easy for you to manage as you one have one login page.