I am in the process of updating an EE site on a dev server. I copied the database and all the core files over and in testing the links many (not all) are coming up with the session number in the middle of the URL as follows:
http://dev.myurl.com/S=169fe023498b4203567a5c3db2629348c99908d1/blog
I have never seen this before and it breaks the links. Any clue what is causing this and more importantly how I can get rid of it?
Thanks.
That's a preference under Admin > Security and Privacy > Security and Sessions.
Set User Session Type to Cookies only. Any selection that contains Session ID will use a token in the URL to track the user's session.
If you're using config-file overrides, this triggers the same thing:
$config['user_session_type'] = "c";
In the EE control panel, if you go to Admin -> Security & Privacy -> Security & Session Preferences, what do you have under "User Session Type"?
If "Session ID" or "cookies and session ID" try changing to cookies only (leave "control panel session type" as "cookies and session ID"
Related
I've heard that my site can get attacked by hackers who:
Go to my site to start a session.
Somehow get a client to go to my site with the same session ID
The client logs in
When the attacker comes back to my site with the session id he has full access to that clients account.
I can see this being done if the session ID is passed by url and it makes sense to cycle it (session_regenerate_id) but is this needed if I just use session_start and I don't put the session id in url at any point in time?
There are session fixation attacks other than session-ID-in-URL. In particular, browser controls over cross-domain cookies are weak.
If an attacker has control over foo.example.com, for example by means of an XSS hole in an application running there, they can write a session ID cookie with parameter domain=example.com, which will then be passed to your application running at bar.example.com and hey presto session fixation.
As a developer you often don't have any control over what other vulnerable applications might be running in neighbour domains, so it is best to assume cookie injection can happen and recycle sessions on a princpal change.
Well, if the session ID is only transferd by a cookie (is not in the URL and you do not accept one in the URL) then it is not that important to protect against session fixation attacks by recycling the session ID.
However it is still good practice, as this could also help against a session cookie which was laying around longer time (and potentially be placed by a former user). So with most security practices it is the same here: just do it, even if you cant find a way it might get exploited.
I am using Glimpse for tracing web request. I have made below setting in Web.config on testing server.
Web.Config
<runtimePolicies>
<ignoredTypes>
<add type="Glimpse.AspNet.Policy.LocalPolicy, Glimpse.AspNet" />
<add type="Glimpse.Core.Policy.ControlCookiePolicy, Glimpse.Core"/>
</ignoredTypes>
</runtimePolicies>
so I able to run Glimpse on All client machine without making On/off from Glimpse.axd
My Question is Currently it is showing me browser name as Client Name , how can I show User name as Client Name like User1, User2 in Client.
The Glimpse.axd does not only allow you enable/disable Glimpse (which in your setup is not needed anymore), but it also allows you to set the client name. This SO Question gives you more details about the how and why.
If you don't set it yourself explicitly, then at some point Glimpse will do this for you. Basically if Glimpse can't find a cookie named glimpseId as part of the request and it is allowed to set a cookie as part of the response (determined by IRuntimePolicy implementations), then it will create that cookie with the name of the logged in user as the value or, when no such user exists, it will create a name based on browser details sent with the request, which is what you are seeing.
Now the funny thing about this, is that this is exactly what you want, but the sessions are still named based on the browser being used. The reason for this is that Glimpse is activated out-of-the-box in your case, as the ControlCookiePolicy has been disabled and that the very first request you make to your application, lets say to log in, will already create that cookie as it cannot find that glimpseId cookie and its value will be based on the browser details sent with the request and not on the logged in user, as there is none yet.
So if you remove that cookie with developer tools of your browser for instance, and you make a new request as a logged in user, then you'll see your name as the session name (beware only for the subsequent requests, as processing of that request will set the cookie as part of the response)
You could also write that cookie explicitly as part of your log-on procedure to make sure it is explicitly set to the name of the user, even if the cookie already existed as part of the request.
One downside, the cookie is not linked to any user session, which means that if a user logs out or the session expires, then the Glimpse cookie still remains and each subsequent request will be labeled as if the logged in user made it, which might not be the case any longer.
I able to set Client Name setting Cookie glimpseId as below.
$("#UserName").change(function () {
var userName = $('#UserName').val();
document.cookie='glimpseId='+ userName +';path=/
;expires=Sat, 01 Jan 2050 12:00:00 GMT;';
});
I get help from below link.
What does "Set Glimpse Session Name" do?
Now my updated output as follow after login with Admin username.
I have a web application inside which there are multiple other web applications. To use them user need to authenticate itself by entering username password. I want once user logs into my application it should automatically logged in other application.
I don’t want to keep same username and password for every application but this will be my final resort.
I can ask user to authenticate itself for the first time and after that my application should be able to do it.
What possible approach /options I have in this scenario.
My application use javascript at client side.
Thanks
You want to create something like StackExchange authentication system. You can use cookies to save data in it. e.g You can create Login cookie for about 3 days life time. It means that your users can login for about 3 days. Cookies are not safe (specially for storing important datas like passwords). To secure cookies you can hash your data. But even doing this the user can delete cookies from browser; Or if user clean its browser history on exit, cookies will be deleted.
Here web have code for creating cookies:
HttpCookie loginCookie = new HttpCookie("LoginCookie");
After that you can set cookie expires (life time):
loginCookie.Expires = DateTime.Now.AddDays(3);
And you can insert data in it:
loginCookie.Values.Add("password", "Hashed value of password here");
For Logout: Create button and set this code in Click event:
Response.Cookies["LoginCookie"].Expires = DateTime.Now.AddDays(-1);
Its better to use sessions. They are more safe. How to create sessions:
Session["Password"] = "Hashed value of password here";
And in logout button (Remove all sessions):
Session.Abandon();
Removing specific session:
Session.Remove("Password");
When a user hits login page of a Portal (it could be Liferay, Jboss Portal..), JSESSIONID cookieis created by the container. After entering credentials in the login page, same JSESSIONID gets carried over.
Here, end user will come to know the JSESSIONIDbefore he could get authenticated (by checking the JSESSIONID in the login page). This will increase vulnerability of the site for hacking because one can know the JSESSIONID before one gets authenticated.
This post advices to have a different JSESSIONID after authentication.
So, creating a new JSESSIOND can be achieved by Portal server being used (am using Liferay CE 6.0) or it has to be handled by web application developer? If it has to be handled by web application developer what is the best way to do? request.getSession(true) is the only option?? If I need to instruct Liferay to create a new JSESSIONID after authentication how it can be done?
This looks a lot like the session fixation problem I solved for Liferay 5.2.5 a long time ago. The solution consists of creating a custom Tomcat Valve that will force a new session ID. So the solution isn't really specific for Liferay and is dependent on if you use Tomcat or not.
I suspect it shouldn't be too difficult to adapt my old solution to a newer Liferay/Tomcat combination. You can find the necessary information about my solution in my old and currently unmaintained blog (if I only had more time...): Fixing session fixation in Liferay
The problem here is not that the user knows the session ID (the user always knows it, it is sent by his browser). The attack scenario is that the user, while logged out, clicks on the link that already has JSESSIONID embedded, then authenticates and this session becomes a logged-in session. Now someone who initially created the link can use the same session to act as the user. More details at https://en.wikipedia.org/wiki/Session_fixation
So yes, use the web or app server to re-set session ID after a user authenticates. You do not need to write it yourself. For Tomcat 7: http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
You can fix this issue by setting the following property to true like Liferay has as default.
#
# Set this to true to invalidate the session when a user logs into the
# portal. This helps prevents phishing. Set this to false if you need the
# guest user and the authenticated user to have the same session.
#
# Set this to false if the property "company.security.auth.requires.https"
# is set to true and you want to maintain the same credentials across HTTP
# and HTTPS sessions.
#
session.enable.phishing.protection=true
#Thiago:
This session.enable.phishing.protection=true is by default true in portal.properties. Anyhow, I have added this entry in portal-ext.properties. But, even then JSESSIONID remains same before and after login.
I have implemented a filter as per this link. After implementing this filter, when I hit login page of Liferay, one JSESSIONID gets created. After I enter the credentials and login, the same JSESSIONID is retained.
I have implemented this filter in a Servlet and not in any of my Portlets or in Liferay's ROOT application. My Servlet is deployed in LR + Jboss AS bundle. Am first hitting the Servlet and from here I have a link which will redirect to Liferay's login page. I have implemented this filter in my Servlet because Container will append JSESSIONID for first time request as it doesn't know if cookies are enabled or not. Since, JSESSIONID is getting appended, am not able to retrieve my images in Servlet (because url is myImage.jpg;jsessionid=). Hence, I have implemented this filter.
Is this filter conflicting with Liferay's configuration? Even after setting session.enable.phishing.protection=true same JSESSIONID is retained means what else could be the problem?
Put this code inside the portal-ext.properties.
It will fix the problem, each and every time logged in, new session id will be generated.
session.enable.phishing.protection=true
com.liferay.util.servlet.SessionParameters=true
I several classic ASP websites that use session state for maintaining login state and user preferences. The code doesnt read or write to any cookies, it just uses "session" variables which rely on the default ASPSESSION cookie SET by IIS.
As no data is actually written / read to the cookie in ASP code (only IIS reading the cookie and linking the user to a session ID) - I would interpret this usage of cookies as having no privacy impact / being "privacy neutral", so I would not need to inform the user of the use of cookies.
Link to ICO Guidlines
You should analyse which cookies are strictly necessary and might not need consent.
and more:
It might be useful to think of this in terms of a sliding scale, with privacy neutral cookies at one end of the scale and more intrusive uses of the technology at the other.
However, I am not a lawyer.
So, I guess I am asking:
1) Is your interpretation of this usage of cookies in agreement with my view that these are "Privacy Netural" cookies, and wont require consent?
2) What situation have you faced with your use of cookies, and what changes you made to comply? (eg, popups, expaned T&C's etc)
3) Any other thoughts?
Thanks again,
Williard