If we are not hitting the site for a long time,it says cms site not found.And then if we need to give the full url. i.e localhost:9001/acceleratorstorefront/?site=electronics
The Session contains the cmsSite (or web site in other words). this value is used as long as the session is alive. When the session expires, the cmssite value doesn't exist anymore, and you should provide it, by following one of the url patterns related to the site you wanna display (which is in your case localhost:9001/acceleratorstorefront/?site=electronics
Please check the CmsSiteFilter, it contains all the code responsible for that behavior.
That is because Session timeout has been set in your accelerator storefront web.xml file.
Hybris filter set that values in Session and this is being used when you hot any button.
Session timeout is a common thing, just look inside web.xml for Session timeout setting and you can increase it to anything you want for testing and development.
You need to use a url that matches one of the urlPatterns on the CMSSite.
Go HMC > WCMS > Websites, look under the Configuration section of the Properties tab.
By default you should use http://electronics.local:9001/yacceleratorstorefront/ and map that host in your hosts file.
Using ?site=electronics sets the Site in the Session, so when this expires you will need to set that again of course. This is done automatically for you when matching against a urlPattern.
Related
Several documents on the ForgeRock site mention to change the iPlanetDirectoryPro cookie name in openAM 10 but never mention which file(s) to change it in. I've tried several including AgentService.xml and AMAuth.xml to no avail. Has anyone does this successfully?
You don't have to change it in files, the files you mentioned are 'OpenAM service descriptions' which are loaded into the configuration store when OpenAM is configured.
Later on you have to change the service attributes using either the console or ssoadm.
You can change the name of the SSO session tracking cookie by changing value in 'server defaults' under 'servers and sites'.
If you have Agents running in normal SSO mode, be sure to adopt the value there as well.
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
On session timeout we re-direct to the login page and if the user logs back into the portal he gets re-directed to the page he was trying to navigate in the first place.
In our case, the re-directed page tries to fetch values from the session and it fails badly with exceptions and it works just fine when there is no dependency on pages which don't have any dependency on session variables.
What is the best way to handle the situation? Can we just redirect this to the home page instead, if so how to do this?
It depends on how much information you are storing in the session, as a guideline, you should always the "shortest" scope ever.
Probably your best option is to allow redirect only on stateless pages, so that it won't give you any problem about inconsistent state.
As for your last problem, take a look at this: redirecting-on-session-timeout-in-jsf-richfaces-facelet. Just set the tag to whatever you want.
I found that IE7 maintains same session for multiple tabs in a single browser window and thus doesn't support different sessions for different tabs in a single browser window. My client needs that the application should work perfectly in two different tabs in a single browser window. i think this is because of session and cookie problem. Is there a workaround for this.
Appreciate your help in this regard.
Thanks,
Manoja Swaro
Browser tabs share cookies (and not just in IE, in Firefox and the others as well), and the cookies contain the session ID.
You could switch to cookie-less sessions however this has security and usability concerns. URL based sessions are easily hijacked, and it breaks bookmarking as well, as each page has a unique URL per session.
IE7 doesn't maintain a 'session' as such, you're talking about a cookie with a session ID in it, I would guess. All browsers will have one value for a cookie, it doesn't vary by window/tab.
If you want a session ID to travel with the click trail, you're going to have to pass it from page to page, by (for instance) passing it as a URL parameter and ensuring that you add the parameter to the URL within the page. (Or do without a session.)
The real solution is to change your application so it doesn't assume each session has only one page. An application that can't be open in multiple tabs is broken.
This can be hard if this assumption is already deeply embedded in your code.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
What are some guidelines for maintaining responsible session security with PHP? There's information all over the web and it's about time it all landed in one place!
There are a couple of things to do in order to keep your session secure:
Use SSL when authenticating users or performing sensitive operations.
Regenerate the session id whenever the security level changes (such as logging in). You can even regenerate the session id every request if you wish.
Have sessions time out
Don't use register globals
Store authentication details on the server. That is, don't send details such as username in the cookie.
Check the $_SERVER['HTTP_USER_AGENT']. This adds a small barrier to session hijacking. You can also check the IP address. But this causes problems for users that have changing IP address due to load balancing on multiple internet connections etc (which is the case in our environment here).
Lock down access to the sessions on the file system or use custom session handling
For sensitive operations consider requiring logged in users to provide their authenication details again
One guideline is to call session_regenerate_id every time a session's security level changes. This helps prevent session hijacking.
My two (or more) cents:
Trust no one
Filter input, escape output (cookie, session data are your input too)
Avoid XSS (keep your HTML well formed, take a look at PHPTAL or HTMLPurifier)
Defense in depth
Do not expose data
There is a tiny but good book on this topic: Essential PHP Security by Chris Shiflett.
Essential PHP Security http://shiflett.org/images/essential-php-security-small.png
On the home page of the book you will find some interesting code examples and sample chapters.
You may use technique mentioned above (IP & UserAgent), described here: How to avoid identity theft
I think one of the major problems (which is being addressed in PHP 6) is register_globals. Right now one of the standard methods used to avoid register_globals is to use the $_REQUEST, $_GET or $_POST arrays.
The "correct" way to do it (as of 5.2, although it's a little buggy there, but stable as of 6, which is coming soon) is through filters.
So instead of:
$username = $_POST["username"];
you would do:
$username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);
or even just:
$username = filter_input(INPUT_POST, 'username');
This session fixation paper has very good pointers where attack may come. See also session fixation page at Wikipedia.
Using IP address isn't really the best idea in my experience. For example; my office has two IP addresses that get used depending on load and we constantly run into issues using IP addresses.
Instead, I've opted for storing the sessions in a separate database for the domains on my servers. This way no one on the file system has access to that session info. This was really helpful with phpBB before 3.0 (they've since fixed this) but it's still a good idea I think.
This is pretty trivial and obvious, but be sure to session_destroy after every use. This can be difficult to implement if the user does not log out explicitly, so a timer can be set to do this.
Here is a good tutorial on setTimer() and clearTimer().
The main problem with PHP sessions and security (besides session hijacking) comes with what environment you are in. By default PHP stores the session data in a file in the OS's temp directory. Without any special thought or planning this is a world readable directory so all of your session information is public to anyone with access to the server.
As for maintaining sessions over multiple servers. At that point it would be better to switch PHP to user handled sessions where it calls your provided functions to CRUD (create, read, update, delete) the session data. At that point you could store the session information in a database or memcache like solution so that all application servers have access to the data.
Storing your own sessions may also be advantageous if you are on a shared server because it will let you store it in the database which you often times have more control over then the filesystem.
I set my sessions up like this-
on the log in page:
$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR']);
(phrase defined on a config page)
then on the header that is throughout the rest of the site:
session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR'])) {
session_destroy();
header('Location: http://website login page/');
exit();
}
php.ini
session.cookie_httponly = 1
change session name from default PHPSESSID
eq Apache add header:
X-XSS-Protection 1
I would check both IP and User Agent to see if they change
if ($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']
|| $_SESSION['user_ip'] != $_SERVER['REMOTE_ADDR'])
{
//Something fishy is going on here?
}
If you you use session_set_save_handler() you can set your own session handler. For example you could store your sessions in the database. Refer to the php.net comments for examples of a database session handler.
DB sessions are also good if you have multiple servers otherwise if you are using file based sessions you would need to make sure that each webserver had access to the same filesystem to read/write the sessions.
You need to be sure the session data are safe. By looking at your php.ini or using phpinfo() you can find you session settings. _session.save_path_ tells you where they are saved.
Check the permission of the folder and of its parents. It shouldn't be public (/tmp) or be accessible by other websites on your shared server.
Assuming you still want to use php session, You can set php to use an other folder by changing _session.save_path_ or save the data in the database by changing _session.save_handler_ .
You might be able to set _session.save_path_ in your php.ini (some providers allow it) or for apache + mod_php, in a .htaccess file in your site root folder:
php_value session.save_path "/home/example.com/html/session". You can also set it at run time with _session_save_path()_ .
Check Chris Shiflett's tutorial or Zend_Session_SaveHandler_DbTable to set and alternative session handler.