My web application is receiving increased attention and I need to provide additional security to protect my customers.
The biggest problem as I see it is that the user login data is sent as plain text. My goal with this question is to discern if the following approach is an improvement or not.
In extension I will need to get dedicated servers for my service. This proposed solution is temporary until then.
I am currently running my web application on a shared hosting web server which only provides SSL through their own domain.
http://mydomain.com
is equivalent to
https://mydomain-com.secureserver.com
My thought is to have:
http://mydomain.com/login.php
...in which an iframe opens a page from the secure server, something like this:
<iframe src="http://mydomain-com.secureserver.com/ssllogin.php"></iframe>
I authenticate the user in
ssllogin.php with the (hashed+(per
user based-randomly salted))
passwords from the database.
After proper session regeneration set a session verifying the authentication.
This session is then somehow transferred and verified on http://mydomain.com
Is this approach even possible to achieve? Would this be an improvement of my login security or just move the "point of interception of password" for the attacker to another instance?
All feedback is appreciated.
You don't need an iframe. Just make the action of the login form to point to https://yourdomain.com/login.php . In there you may check if user & password are correct, and then redirect again to plain http.
BUT this is not 100% secure. The fact that you are sending the user & password via https may prevent an attacker or sniffer to get that. But if you later revert to plain http, it is possible to this attacker/sniffer to hijack the session of any logged in user sniffing the session cookies of this user.
If you want more security (not 100%, but more than this previous option), stay always in https, for all resources (css, js, images too, not just your php/html files), and even serve the login page via https.
For some reasoning of these points, see firesheep (for the hijacking session problems) or the recent tunisian gov't attack on tunisian facebook/yahoo/gmail users (for serving even the login page via https).
edit: sorry, I misread your question. If the SSL domain is different than the not-ssl domain, you may have problems, as the session cookie only will work against the same domain or subdomains. So, if you do the login and send the session cookie from https://yourdomain.secure-server.com, it will only be sent back by the browser to yourdomain.secure-server.com (or *.secure-server.com if you will), but not to yourdomain.com. I think it's possible to make a wildcard cookie valid for all *.com subdomains, but it's better not to do this (do you want your users' session cookie be sent to evil.com ?)
Related
When I read about something "PHP Session vers Cookie" often I found cookies are not mentioned to be save because they are stored at the client side in the browser. And of course a hacker can get access to the PHPSESSID cookie and get the session_id.
So meanwhile I am a little bit confused about the recommondation to run PHP always with the php.ini statements "session.use_cookies = 1" and "session.use_only_cookies = 1".
What could a hacker do if he get this cookie PHPSESSID whigh includes automatically the session_id?
Would it help to make a statement "session_regenerate_id();" after "session_start()"?
Even then the session cookie will be written to the client side and could be read by a hacker.
Am I right to say this makes the idea of a session cookie - which will identify the user even if the browser will be closed - useless?
This is really confusing.
I am a beginner with the security questions of PHP and Sessions. May be I could find some help here to understand this concept. I read already many post but I did not yet found the answer to my specific question.
The short answer is $_SESSION variables cannot be accessed client side e.g. $_SESSION['variable'] -> NOT stored on client. The $_SESSION id which is used to associate those variables to a client can be accessed as it's stored as a cookie which can be easily manipulated. So for example, if I created a login system which validated a user's credentials, it's common practise to then use this $_SESSION id or a session variable ($_SESSION['loginSuccess']) as the identifier that this login was a success so it can be allowed to access "Locked" pages. A client $_SESSION cookie is only active when the browser is open, if you close the browser down, your $_SESSION cookie will be forced to expire.
The huge security risk is if someone was able to gain access to your session variable using techniques like 'Man in the Middle' attacks (MitM for short). All they would need to do is manipulate there own session id cookie by replacing it with the authenticated cookie and then refresh the page. To get around this, just make your website has an SSL certificate installed from trusted CA (certificate authority e.g. GoDaddy) and enforce your web server to only allow HTTPS connections. This means that all your data transferred from server to client and vice versa is 1-to-1 encrypted.
Even after you have enforced HTTPS, it's worth noting that it's still possible for a MitM attack to be successful and access your encrypted data. This is usually done by the MitM software initiating the SSL acknowledgement on the clients behalf, after that, MitM presents a different SSL certificate (usually self-signed) to the client. By doing this, MitM software can see all encrypted traffic from client and server using 2x SSL certificates. Users would get an error in browser stating the certificate does not match the domain used or is not trusted (because of being self-signed), but as we know, some end users will no doubt accept this.
To overcome this issue, most banks check the validity of the client-side certificate using JS and then confirm server-side if it's valid. I've personally not had to go this length for the security of my sites but I'm sure it wont be long before this becomes best practise.
For MitM Info: https://security.stackexchange.com/questions/65794/it-is-possible-to-decrypt-https-traffic-when-a-man-in-the-middle-proxy-is-alread
For SSL JS: Within a web browser, is it possible for JavaScript to obtain information about the HTTPS Certificate being used for the current page?
For Session Hacking: Can session value be hacked?
After logging in, the cookie is set by the PHP. But the text in the cookie is same for the user. So if someone gets the cookie then one can easily login by using the user's cookie he got.
Although I found that it is not possible to set or edit a cookie in the browser. But if someone (probably a hacker) happens to succeed in editing/replacing the cookies, then he can login easily.
I have tried XOR encryption but that doesnot make any difference.
How can I better protect my website?
Exploiting authentication process using cookies is part of session hijacking. You should learn that it is not only cookies which make your scripts vulnerable to this kind of attacks.
The impenetrable solution is HTTPS. The compromise for using cookies to store your login information is using HTTPS along side.
One doesn't have to have access to your PC to sniff your cookies and hijack the session. It can be done in a LAN or even in public wi-fi using simple programs as long as all your data are not fully encrypted end-to-end.
Warning: Header only encryption is not enough. See FiresSheep section of the following article
Session Hijacking
I wrote a PHP application which requires a login. This application is private so no new users can register. First I used sessions to identify the users but it lead to problems on tablets because they lost their sessions. I think this is because of energy saving operations.
Now I changed my application to generate a random security token. So the authentication is as the follows:
Log in
Generate random security token and save it to disk
Redirect the browser to http://myhost/site?id=[securitytoken]
On the server side I check if the file exists - if yes, user is authenticated
Everything is now working perfectly I am just thinking about security concerns. It is no problem if the user sees the security token. Is it somehow possible to find out the token when I use GET? I am using SSL.
I tried to change the expiration times and cookie lifetimes. On a normal computer it is working as it should. On the table it is also working IF it does not go into standby (meaning the screen gets black). If the screen gets black, the session expires very soon.
There is no vulnerability inherent to using GET instead of, for example, POST from a network perspective.
The only caveat you should keep in mind is that a GET request is more likely to be stored on the client (e.g. browser history) in a way you might not intend. For these reasons, I typically use POST requests for authentication.
The problem you are attempting to solve sounds remarkably similar to "remember me" cookies. The linked blog post might be helpful in mitigating the security risks involved in designing token-base authentication systems.
Generally, web apps are confined to using localStorage and cannot silently read/write to files in the background. How are you accomplishing this?
When you say you're using SSL, do you really mean TLS or do you mean SSL version 3? If SSLv3, I would advise updating your stack and webserver configuration to support current best standards. TLSv1.2 with ECDHE and AES-GCM + SHA2 or ChaCha20-Poly1305 are ideal.
GET is more vulnerable than POST as it can be transmitted and stored:
In server logs by default.
In corporate proxy logs.
In the referer header if your page uses external resources or links to external domains.
In your example you have a http URL (this could be a typo though as you said you are using SSL). Make sure you are using https URLs to protect this data in transit.
This approach could also be vulnerable to Session Fixation as an attacker could get the user to visit a URL containing, or redirecting to, the same session ID as the attacker. When the victim logs in, the shared session will be authenticated meaning the attacker is now also logged in. To protect against this, refresh the session ID upon login and logout.
Cookies are often the preferred approach for session handling as they are harder to attack in the above scenarios.
The issue with in URL variables in the get form means that for one : users can easily modify it (by accident or not) and they stay even when the link is copied somewhere.
If you send someone your link/someone gets your link with the id variable in it,is that a security risk to you?
Im familiar with reading cookies using php, but i was wandering if there is a way you can read a users browser cookies set by another 3rd party site (ie. not your own.)
Could somthing like this be written to view all of the users set cookies ?
print_r($_COOKIE);
No, it's impossible.
You can only read cookies that come from your own domain. The other cookies are not even sent to your server.
If you could read every cookies the user has, you would be able to obtain personal information such as their facebook password, connection to their bank etc.
It would be a serious breach of privacy, and as such, browsers do not send cookies except those from the same domain.
No
When you visit a website, your web browser requests information from that domain (somedomain.com), and that third-party domain is allowed to set a cookie. Each domain can only read the cookie it created, so there is no way anotherdomain.com could access the cookie created by somedomain.com.
To read a cookie you must match the domain that the cookie was originally created under. Browsers consider this a security principle and will not let a site access any cookies that they did not create.
Note that there are several other security considerations that could potentially circumvent this rule, such as DNSMasq in combination with spoofed browser certificates. This is why DNSSec (and SOPA) were such a hot issue; the security hole DNSSec plugs will also protect your cookies from getting stolen from your cookie jar.
There are real-world examples of security holes that have leaked in the past. See here for an example of an even different security vulnerability from 2008.
No, this is not possible, because browser only sends the cookie that set by your domain, usually, it's attached to header of the HTTP request if previously being set by the domain.
Third party cookie are those cookie that set by another domain in the context of the target domain, for example: while opening example.com it might has a banner from another website (example2.com), at this case, if example2.com set cookie it can't be read by example.com because they are from different Origin that Browser prevent even scripts to access it.
No, of course not. Otherwise your website would know my bank's login cookie, and you'd be able to steal all my money. Cookies are only available to the domain that set them.
I have a user login/reg system with a user management admin area.
Just some background:
Currently the login is all 'ajaxy' so the user clicks login and the loading gif swirls around while in the background the details are checked, sessions created.
If all goes well the client side javascript refreshes the page to the correct location.
the questions
Now if I wanted to use SSL, what do I do?
The "ajax" call - I need to secure this - do I do this by making the call to https - is that enough?
1.1 Currently I use jQuery $post which has a relative path to the login.php to check the user login details. Should I make this absolute - eg https://www.mysite.com/ajax/login.php
Should the redirect after login also go to https
(the site owner should already have a SSL certificate etc)
Thanks
Everything needs to go through SSL.
If the page is HTTP and the Ajax goes to HTTPS then you'll bounce off the same origin policy
If the conditions are as above but you use CORS to work around the policy then a man-in-the-middle attack could alter the page the request is made from and add (for example) extra JS to steal the credentials from the page (instead of from the HTTP request)
If you redirect to HTTP once the user is logged in, then you are vulnerable to the Firesheep problem
So display the login page via SSL, and once the user is logged in, keep using SSL.
Everything that's sent over an SSL connection is encrypted, so yes; making your AJAX calls use SSL will be enough. In practice, you will also need to have the page that's issuing the AJAX calls use SSL to avoid origin policy problems.
Whether you redirect to a relative or absolute path doesn't matter security-wise, it's only a matter of taste.
Assuming you don't want the user's cookie or other actions to get sniffed, then yes, after the user has logged in, all the following communication should also be using SSL. HTTPS doesn't cause much overheat, so there's generally no reason to not use it if it's available to you.