I have been tasked with attempting to fix a problem with session management in a webserver. The code is written in c and is pretty old. Sessions are limited to creating a folder for a new session and a little php script runs on top and checks the SID is valid for a logged in user.
However the way the program works the SID is stored in the URL! so any copy pastes result in session hijacking. Now I've been told its not possible to change the fact that the SID is stored in the URL. It is not possible to use cookies as some customers have high security settings in their browsers and this also cannot be changed. The only things I can think of are URL rewriting storing the SID in a hidden field but I am still waiting for information from my manager, I don't think it will be possible as the HTML files are pre written and I don't think it is possible to add hidden fields to them, maybe this can be done on the fly by the server program, I'm not sure. And my last idea was to use tokens, or just to start a new session if a different IP address or User-Agent string is found even if it has a valid SID.
I don't really know much about web security I am on a placement year from University and mainly C programming but have been given this task as a little side project which I would like to try and accomplish something with.
Do any of you have any pointers?
I know I've been vague and I'm not allowed to post any code :( sorry
Thanks for you help in advance though.
Even with already existing session managers, the only way to avoid session hijacking is to also validate against the client's IP address and optionally the user agent string as well. Any of the other suggestions can be done just for obscurity, but won't have any effect if somebody decides to try hacking into your app.
Related
There is any way to check the login status through different programming language?
Right now I'm using three session (same name) that starts at the same time after the login process, using ajax.
Right now, the login.html form is processed on three files: login.aspx, login.asp and login.php but it's seems too slow and weird. I'm combining three different services from the same company into one, after re-building the users and others common tables in mysql, everything seems to work fine, but I'm really scared about security bugs.
Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
This sounds like single sign-on to me. Let's try to split the problem.
There is any way to check the login status through different programming language?
You're not really interested in the language used. Any language, given the same info and algorithm, would decode with success the same encrypted data. I guess you're instead having problems because PHP's application logic regarding this point is different from the ASP's one.
So for the first point, you can
Implement / normalize the same session checking logic among all of your apps. This is probably unfeasible, because you might be using Laravel here, and ASP.Net on the other, and the two are probably slightly different in this regard. If you can, do this, or...
Look into JSON Web Tokens. I won't go into detail, but these were more or less designed to solve this class of problems. They are also easy to handle, but be aware, there are aspects you have to take care of when using them for user authentication.
[...] Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Not to be that guy, but some concepts are somewhat deformed here. Sessions don't expire on files; they normally are setup with a given expiration time and a given domain. So generally speaking, a session opened from a PHP app, and stored on a cookie, then read from an ASP one shouldn't change, given that no difference exists between the two app's session handling logic.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
For both of the solutions i suggested above is, especially for the cookie one, it's important you make the apps absolutely identical in respect to session handling. While this is trivial with JWT (as there's barely any logic on the app's side), this may prove to be harder with cookies if the authentication logic comes from some one else's code (as in a framework).
I haven't asked about single sign-out, and at this point i'm afraid to ask :). But these are some guidelines:
If going the cookie route, be aware of cookie's domain. A cookie is normally valid for every request coming from the website domain (name.com), but you may have some of your apps under a subdomain (like, phpapp.name.com). In this case, be sure the cookie created from the given app is valid for the whole domain, and not just the subdomain. And make the apps available at subdomains / pages under the same domain. Cookies don't work cross-domain, and you have to deal with that, since cookie domain policy is enforced at browser level.
Launching three AJAX calls means triggering three login procedures. I suppose all of these would terminate, at some point in the future, and all of those would be storing / rewriting the cookie. If the apps understand the same cookie, it's mandatory you open the login process on just one of them. This would store the cookie, which would then be automatically picked app from, say, a page in the second app, giving you a seamless transition into a logged-state in the second app.
JWT would normally require some JS work, which you may like since the same script can easily be loaded in all of your apps. On the other side, you can be sure that different server libraries handling JWT would all work the same for you, thus ensuring compatibility.
Personally, i would look into JSON Web Tokens.
You can develop your own session provider which stores data in a separate place (for ex. in database or files). Then everything you need to do is write some code in every environment to handle your session information from that provider. Because you use only one source to store session information there will be no problem with synchronization between any of yours environment.
If you need then you can use a webservice for exchange session information between every environment and session provider. Every application can use security connection to get and set information about session from that session webservice.
I think you can do this!You can create provider which stores data into database. Then Write some cool code to manage your provider.You can also use webapp or sevice.Every service use security to get and put information.
I'm busy creating a login system to the admin area of my new personal website. The site backend is written entirely in Python, owing to my knowledge of the language.
I have been looking at ways of tracking a user once they login so that the rest of the site knows they are logged in.
I can't get a definitive answer online (unless I'm not looking hard enough or are searching the wrong thing) as to whether are all cookies are the same and accessible from all languages. My tests have proved inconclusive; either they are not or I am doing it wrong but some clarification would be appreciated.
For example, if I create a cookie in Python with cookie.SimpleCookie() in the http.cookies module, is there a way of loading and accessing the value of this cookie in PHP?
Thanks in advance for any help,
Ilmiont
Cookie are just cookies and browsers don't record (and possibly can't) how they were created. So when you create one cookie using PHP and then you would like to read the same cookie using any other language that support cookie, you should do it without a problem.
Of course you need to remember about cookie domain and path. They should be set properly if you want to access your cookie without a problem.
I've build a PHP web application which I only want my wife and I to have access too. Adding password protection adds an unnecessary user step - is it possible to restrict the page to certain devices (e.g. our iPhones, iPad and MacBook) regardless of wifi / 3G network etc.
I don't think PHP can determine MAC address - so is there a suitable method other than password protection?
Thanks,
Mike
EDIT
Some further info to help clarify:
The server is running on Debian/Linux (The RaspBMC off-shoot of Raspbian to be precise).
I need access from anywhere, home and out and about.
Thanks
Security through obscurity?
Technically, any device could still access the application, although it would take a 'while' to do it, especially if you force a sleep (Guessing a simple combination of 10 digits would have a maximum guess time of 300+ years at a sleep of 1 second, so it's pretty unlikely someone could guess it correctly). For example:
sleep(1); // Deter brute force
if ($_GET['auth'] == 'sdfjksahdkfjshadkjrfhwaoieua3487a3wt897dywydd39d87haw387d8a3hd7a8hd387wahd089afh980a3yfh983ahf398ahsdaf') {
//run app
} else {
//throw 404
}
Save the link to the app on the devices you want to access it like so:
http://www.applocation.com/app.php?auth=sdfjksahdkfjshadkjrfhwaoieua3487a3wt897dywydd39d87haw387d8a3hd7a8hd387wahd089afh980a3yfh983ahf398ahsdaf
Lose your phone/tablet/whatever device you have a link to the app on, and security is immediately compromised, but considering you don't want to go down the password route, that would be the case anyway.
This will cover the majority of your security needs. It's not secure, so if accessed it via a dodgey public network which people were snooping on, it's security is compromised. However it depends how secure you need it to be. If you're storing bank details/passwords on a webpage (which is a terrible idea anyway), I personally wouldn't even consider this option; 'just in case'. Although if it's fairly minor stuff that doesn't matter that much, it's absolutely fine. The main idea behind this is just to stop people from accidentally accessing things you don't want them to see.
Besides, if you think that maybe someone has found it out, you can just update the auth string to something different anyway.
There are actually ways to get the user's MAC address, but these can be spoofed anyway.
I would recommend making a cookie, for you and her, and requiring data from it (like a key) as authentication, with it updating every now an then.
Updating it would protect against people that had manged to get a copy of the cookie (somehow...) from using it forever.
It could also be something like sending every request with a 'automated' username/password/auth key, into the post or get variable, to be checked by the server. Also has downfalls, as someone could be sniffing your packets. But at that point, you probably have bigger problems.
What you're trying to achieve is not possible. HTTP isn't designed to provide hardware-specific identifiers, the only "identifier" is the User-Agent which isn't identifying at all, and it can be spoofed, so the browsers don't even access that information.
It's not technically possible.
I am just looking for some advice on the new UK Cookie Law and how it affects PHP sessions. I understand that you do not need the users to opt in when a cookie is "strictly necessary" and the example given is adding an item to a shopping cart.
I am using similar functionality that remembers what you have stored in a contact form, which I feel is strictly necessary use of a session and therefore no opt in is required.
However the confusion for me arises because I have a session_start(); at the top of each page, which means the cookie is set straight away. Some users will not then go to use the contact form, so this means that the cookie is not strictly necessary for them.
I could remove session_start(); from the top of each page, but this functionality is used throughout a number of websites and it would be preferable if we could leave it in.
Could anyone shed any more light on this?
The simple answer is that you're probably going to be okay, the extent to which this law will even be enforced is massively up for debate anyway.
We will enforce the law proportionately. We’ll look at the risks if
and when customers complain to us. If a websites’ cookie and privacy
is a risk to many people, we may then take action.
There is a balance to be struck though, as not all cookies are equal,
and our enforcement approach will bear this in mind.
For example, someone may complain about a cookie placed without their
consent, but if it was just used to remember essential details rather
than to gather information to be used for marketing purposes, then it
may not be appropriate to act.
(Source: The ICO's Dave Evans on EU cookie law compliance)
From what I have heard, the ICO is going to be fairly liberal in the interpretation of the law, the most important thing to do is show that you are making changes to comply with the spirit of the law.
I think that as the form is essential to the site, you don't need to prove that it is essential to 100% of users.
In an ecommerce site it is being taken as read that it's ok to have cookies that relate to shopping bag without asking permission, as it is essential to the function of the site, even if a particular user doesnt actually add anything to their basket.
No, I think the php sessions donot fall under the Cookie Law. There is are a lot of differences between Cookie and Session.
For example, read here:
http://php.about.com/od/learnphp/qt/session_cookie.htm
Also, if you read the law:
http://www.bis.gov.uk/assets/biscore/business-sectors/docs/i/10-1132-implementing-revised-electronic-communications-framework-consultation.pdf
It says,
"The provisions of the amended Article 5(3) refer to any attempt to
store information, or gain access to stored information, in a user’s
equipment" (pg 57)
So you see, it says "user's Equipment" and sessions are not stored there, they are stored at server http://ejvyas.blogspot.com/2010/02/where-is-stored-is-it-in-browser-or-at.html
If you're able to store a PHP session cookie on a user's computer to enable the 'essential' functionality of your website - what stops you then associating additional information with that visitor without their consent/knowledge..? (Apart from it being illegal.)
After all, all the information you store - except the cookie ID which is client side - is kept on the server side and the user can't do anything to view/modify this?
So in short, if the user 'allows' you to store a PHP session cookie on their computer there's nothing to stop you storing lots of other data about their visit? - IP, Browser, OS etc...
Having read GDPR and having knowledge of how sessions work in php I have to tell you this:
1. session_start() in php is called before headers because you cannot send additional headers (as php session does) after the page loads and headers have already finished.
2. Because this happens sessions in php is an essential thing of the language itself for the language to work properly so it is something you need. Not want.
3. A php session stores a cookie in the users machine with the session id to know the connection. Not the user. For example the server says "I have a request from someone. To not mix the requests from everyone keep an id of everyone". The person, ip, geolocation or any other data is not known at the time. To be clear of this session_start() not storing any other data but the session id is how the server side language php and the server itself works and it is not possible to have consent before you initialize it.
4. But: before storing any other data you have to inform. I believe you have to inform when you start doing it, how you do it, how long you do it and what you are storing. So no more tracking on guests. Third parties like google, facebook and other implementations on your page is another story. You should pretty much remove it for guests if third parties don't allready do.
Simple: starting a session before headers is mandatory for php. Storing data needs consent so when the user logs in, registers or any other interaction inform the user and store a consent in the database (for you) and in the cookie itself (for the user to know).
Hello guys I am new in Yii framework and first of all what I am starting to do is creating user register/login system. I really want my system to be secure, but I found out that using cookies is not the safest method at all. So I have some suggestions that can be interesting, please remember that I am not professional PHP programer, so this suggestions can contain some bugs, but I think we will fix them.
As I understand when someone visits Yii website, first of all Yii tries to get the cookie and checks if it is already logged in. So why we can't use database instead of cookies? What I mean is that we can have this fields in database:
ip
remember_me
latest_visit
So, why we can't let Yii to check database instead of cookies? What I mean is that to let Yii check if guest ip == ip from db and remember_me == true, and latest_visit was not before 7 days. So instead of cookie validation using this method will be better. And after that let Yii to do whatever it does after cookie validation.
What we will achieve is remember me method for non cookie enabled browsers, avoiding cookie stealing and making user login system more secure since every data will be stored in the server side and on the client side will not be stored anything.
So how to do this? What do you think? how to make Yii do the task?
IP addresses do not identify things reliably; there can be NAT (network address translation) at play so that multiple machines appear to come from the same address, not to mention DHCP leases expiring, and the possibility of different people using a single machine (kids using Dad's machine?) and so on. So, with the information given, you'd have zero proof that the browser has even visited your site before. Of course, some people use multiple browsers from a single machine (say Firefox, Chrome, Safari); cookies for one will probably not be available to the others.
What you are suggesting is woefully insecure. Please don't try it for production use.