Same Session ID on Same IP Address but Different Ports - apache

I am running my website (exactly same source code, even user login detail) on two different computers, each have their own apache.
Users can access both websites via my port fwd setting.
For example, 10.10.10.10:81 to access website on computer A and 10.10.10.10:82 to access website on computer B.
User have no problem to access either one of them. Until user wanna access both of them at the same time using the same internet browser.
Login to website on computer B will log him/her out from website on computer A.
Why this happen?
Because same IP Address will auto generate the same Session ID?
Different ports won't have different Session ID?
How to avoid this? Manually generate Session ID will do? Any other solution for this issue?
Thank you.

Cookies are not specific to a port.
It means if a server that runs on 10.10.10.10:81 sets a cookie sessionId=123455 the same cookie will be sent to a server that runs on 10.10.10.10:80 . It leads to the scenario you described
A user goes to server 10.10.10.10:81
10.10.10.10:81 server establishes a session for that user and sets the cookie.
The user logs in into the server and now can use the session to browse around.
User then goes to 10.10.10.10:80 and the browser sends the session cookie set by 10.10.10.10:81
Because 10.10.10.10:80 knows nothing about the session on 10.10.10.10:81 it establishes a new session and sets the new session cookie overwriting the old one
The new session cookie is only valid on 10.10.10.10:80 and thus the user is logged out on 10.10.10.10:81
Solutions
(Prefered) Configure different names for session cookies
OR
Configure the server to pass the port parameter when setting the session cookie header. This will make the cookie specific to domain+port combination. Avoid this solution if possible because not all the browsers deal with this parameter correctly.

You've not given a lot of information, but if sessions are being maintained using cookies, and the same domain name is being used to obtain access to both sites, then the cookies will apply to requests to both sites.
When the user switches from site A to site B (using the same browser instance), the session cookie will be sent, but won't match an existing session ID - so a new session ID will be generated by site B and set as "the" session cookie.
Two general approaches to solving this - either use two different domain names for the two sites, or distinguish the session cookies in some other manner. You might be able to do this by configuring a different name to use for the session cookies in site A and site B. The specifics of doing this depend on the technology being used to create sites A and B - which you haven't told us about.

This is the example to solve it:
127.0.0.1:110
session_start();
$_SESSION['ss'] = 'll';
echo '<pre>';
var_dump( $_SESSION);
ouput:
array(1) {
["ss"]=>
string(2) "ll"
}
127.0.0.1:111
session_start();
echo '<pre>';
var_dump( $_SESSION);
ouput:
array(1) {
["ss"]=>
string(2) "ll"
}
After change session 's path
127.0.0.1:110
session_save_path('/tmp/sess');//This line must be wrote before session_start(),
session_start();
$_SESSION['ss'] = 'll';
echo '<pre>';
var_dump( $_SESSION);
ouput:
array(1) {
["ss"]=>
string(2) "ll"
}
127.0.0.1:111
session_start();
echo '<pre>';
var_dump( $_SESSION);
ouput:
array(0) {
}
127.0.0.1:111
session_save_path('/tmp/sess');
session_start();
$_SESSION['ss'] = 'll';
echo '<pre>';
var_dump( $_SESSION);
ouput:
array(1) {
["ss"]=>
string(2) "ll"
}

Related

Host Header Injection

I am a beginner in security and reading about the host header injection. I tested an application for this vulnerability and it is possible there for some request but developer implemented no-cache, no-store flags and this vulnerability is not in password reset request.
So first thing is there will not be cache poisoning. and the second is it is not happening in password reset request.
As I understand that for exploiting this vulnerability, I changed that host header. So I want to know why will It be a vulnerability, why a user will change Host of the application? and how an attacker can exploit it?
As in all of the cases the client input on the application should be never trusted (in security terms). The host header attribute is also something that can be changed by the client.
A typical attack scenario would be for example:
Lets suppose you have an application that you blindly trust the HOST header value and use it in the application without validating it.
So you may have the following code in your application, where you load a JS file dynamically (by host name):
<script src="http://<?php echo $_SERVER['HOST'] ?>/script.js">
In this scenario, whatever the attacker set as the HOST header would be reflected on this JS script load. So the attacker could tamper with this by manipulating the response to load a JS script from another host (potentially malicious). If the application is using any Caching mechanism or CDN and if this request is repeated multiple times, it can be cached by the Caching Proxy. Then, this can be served to other users as well (as it was saved to cache).
Another way of exploiting this is:
Let suppose that the application has a user password reset feature. And the application will send an email to whoever asks for a password reset with a unique token to reset it, like the email below:
Hi user,
Here is your reset link
http://<?php echo $_SERVER['HOST'] ?>/reset-password?token=<?php echo $token ?>
Now an attacker can trigger a password reset for a known victim email by tampering the HOST header value to the one of his desire. Then the victim would receive the legitimate email for password reset, yet the URL will be changed to the domain set by the attacker. If the victim would open that link, the password reset token could be leaked to the attacker so it would lead to account takeover.

Can not add account for custom Sonos service

I've created a Sonos music service and added it to my speaker with customsd. Both endpoint urls (regular and secure) are available. The service is successfully added to the speaker.
With SoapUI I can send a https request for GetSessionId and it returns a valid response.
I use sessionId authentication, so when I want to add my account to the service in Sonos, the service asks for a username and a password. After filling in, I get a connection error. Problem with adding account. Connection can not be made.
The problem is, I expect a 'GetSessionId' request entering my music service (So I can debug the request), but it seems nothing comes in.
Can anyone tell me why or what is happening?
Are you setting the authentication type to Session ID when you're adding the service from customsd?
Here is an example of how the function should look like (in PHP):
public function getSessionId($args)
{
$user = $args->username;
$pass = $args->password;
//Check the user and pass in your service
//if login successful, set $sessionId to the session ID of the user
//else if login unsuccessful, throw new SoapFault('Client.LoginInvalid','Client.LoginInvalid');
return array('getSessionIdResult' => $sessionId);
}

Missing Secure attributes in cookies: WL_PERSISTENT_COOKIE and testcookie

In a security scan result, I received the following error:
"Missing Secure Attribute in Encrypted Session (SSL) Cookie" for WL_PERSISTENT_COOKIE and testcookie.
I don't know how to set the secure attribute for these cookies, from the websphere server it just allows me to set the secure attribute for the JSESSIONID cookie but not for the others.
Here are my conclusions from my appscan results:
testcookie: This cookie seems to be generated in the worklight.js file. According to the appscan, the application sends a request to the server (GET /ParkingApp/apps/services/preview/SmarterParking/common/0/default/worklight/worklight.js HTTP/1.1) and the server responds with this file, which has the following code fragment:
areCookiesEnabled : function() {
var enabled = true;
if (WL.EnvProfile.isEnabled(WL.EPField.WEB)) {
var date = new Date();
date.setTime(date.getTime() + (24 * 60 * 60 * 1000));
document.cookie = "testcookie=oreo; expires=" + date.toGMTString() + "; path=/";
var cookie = getCookie('testcookie');
enabled = (cookie.value === 'oreo');
}
return enabled;
}
So I understand that the cookie is set in this file as the subsequent requests and responses exchange the testcookie.
How can I edit this file as it seems a predefined file in worklight? Would it be a good practice to edit this file so that I modify that line to include the secure attribute?
WL_PERSISTENT_COOKIE: With this cookie I'm a little bit stuck, the worklight server looks for this cookie in the request and in case it is not found it sends it back to the client in a set-cookie header. Actually, this is what I'm seeing in the security scan, however the server doesn't set this cookie to have the secure attribute and I don't find the option in the websphere server settings. How could I set the persistent cookie to have the secure attribute?
Thank you very much in advance!
The short answer is that there is no option to set the secure attribute for either of these cookies. These 2 cookies are not considered sensitive. But AppScan does not know if these are sensitive cookies or not and so just reports that there is no secure attribute set.
In the case of testcookie, it is only used by the client to test whether cookies can be set or not. It is not used by the server at all.
The WL_PERSISTENT_COOKIE is a randomly generated ID to associate a request with a user identity when there is no other user identity established. It is used internally to represent an anonymous ID for purposes like tracking/reporting. It is not used for protecting resources that require authentication and authorization. So capturing a WL_PERSISTENT_COOKIE token and using it from another device or another session would not grant any additional or different privileges.
It seems that both testcookie and WL_PERSISTENT_COOKIE are both used by Worklight.
testcookie is just a fake cookie used to check if cookies are enabled and WL_PERSISTENT_COOKIE is used by persistent cookie authenticator as described in the documentation here:
http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.dev.doc/devref/r_persistent_cookie_authenticato.html
I think you can't change those cookies as they are used/set by Worklight.

Authenticating Domino REST Service Requests

I have installed "Domino Sample REST Service Feature" from 901v00_11.20141217-1000 version of XPages Extension Library. OpenNtfSample service (com.ibm.domino.services.sample.service.SampleService) works as it should in general and the only problem with it that it completely ignores authentication settings of the server.
I have tried both Basic and Session Authentication as described in Authenticating Domino REST Service Requests and the result I get is the following - the service returns data always and does not ask for any user name and password.
The server is configured with Session Authentication now and I get password prompt when I try to access
{my_server}/api/data
but does not get it when I open
{my_server}/api/sample
After I had added this Web Site Rule
Description: DAS service
Type of rule: Override Session Authentication
Incoming URL pattern: /api/
the server changed password prompt for
{my_server}/api/data
but
{my_server}/api/sample
remained open.
Has anybody experienced this kind of error? Can anybody help me password protect this sample service so that I could start developing my own once based this example?
The /api/sample resource is wide open on purpose. That just returns a link to the contacts resource -- /xpagesext.nsf/api/sample/contacts.
If you really want to prevent anonymous access to the /api/sample resource, there are two possible solutions: 1) Disable anonymous access for all HTTP requests, or 2) Make a change to the RootResource class. The first solution is a server config change. I'm sure you can find details about that elsewhere. Since this is StackOverflow, I'll focus on the second solution.
As you have already noticed, we don't allow anonymous access to the /api/data resource. You can mimic that behavior in the /api/sample resource with a simple change to RootResource.getLinks(). Near the top of the method, just add these lines of code:
boolean authenticated = false;
Session session = ContextInfo.getUserSession();
if ( session != null ) {
String userName = session.getEffectiveUserName();
if ( userName != null && !userName.equals("Anonymous")) {
authenticated = true;
}
}
if ( !authenticated ) {
throw new NoAccessSignal("Need user context");
}
By the way, you won't need to make the same change to the contacts resource class (ContactsListResource.java). Because the contacts resource URL includes a database name (xpagesext.nsf), the web server will attempt to open the database before forwarding the request to the REST service. You can prevent anonymous access to the contacts resource by changing the ACL of xpagesext.nsf. Just make sure the default access is "No access".

Can I programmatically log a user out of .htaccess authorization?

I'm using Apache "Auth" security to limit access to my web site (via commands in the .htaccess file, an .htpasswd file, etc).
Is there a way to de-authorize a user via my PHP script, effectively giving them a way to log out?
With that type of authentication, the username and password are actually send by the browser on every subsequent request. As there's no way to tell a browser "hey, stop sending those", there is no way to do what you're trying to do.
(If, however, you had a PHP script involved that was handling part of the authentication, you could set a session variable for flagging to ignore the valid authentication and pretend the user is logged out.)
However, in terms of a good solution, there is not one. The user will stay logged in until his or her browser decides to stop sending the headers (usually when the browser is closed).
<?
// this PHP will cause a logout event, and give the login prompt again
$AuthName='WHAT-EVER'; // must match AuthName in .htaccess.
header('HTTP/1.0 401 Unauthorized');
header('Content-type: text/html');
header('WWW-Authenticate: Basic realm="'.$AuthName.'"');
// now redirect them when they click cancel
// should be to a page with no password required.
// use an HTML meta redirect instead of HTTP
// so it runs after the auth is cancelled.
?>
<html><head><meta http-equiv='refresh' content='0;../'></head></html>
Is this what you're looking for?
http://www.php.net/manual/en/features.http-auth.php#99348