+ Start a Discussion
JoyceJoyce 

sessionID

I read in previous post that your sessionID can be re-used?

I read in another post that a few of these items are encryped (user, originating IP, system timestamp, etc.)

If user's originating IP address is passed, why doesn't Sforce check the originating IP Address to verify that it's the original user?

This would add that extra level of security, right

SuperfellSuperfell
There's an option in the security settings to turn that check on/off.
JoyceJoyce

Can you provide more info?

I pass the sessionID to a Web Link, that goes to an external program (let's say an aspX page).  If I click on properties of the aspX page, I can get the generated URL.  This URL can be sent to someone anywhere and it can be processed.  This is a security issue.

I read that the IP address of the originating user, gets encrypted in the sessionID.  If so, why doesn't this get checked as well.

Also, can the IP address be restricted for the hits to the SForce server

Message Edited by Joyce on 04-06-2005 11:44 AM

SuperfellSuperfell
Under Session Settings in setup there's this option
Lock sessions to the IP address from which they originated.

Which means we'll only treat the SessionId as being valid if the request is from the IP that did the inital login call.

At all times, the sessionId is tranmitted over SSL, so is secure from sniffing attacks. The only way to get the sessionId into a WIL, is for your admin to configure the WIL.
JoyceJoyce

Hi Simon, thanks for your answer, but this setting doesn't help

I'm accessing an external application, sitting on a hosting site.  For example,

User1 has IP address 1.1.1.1

User1 logs into Salesforce, access WIL which has SessionID passed to a program sitting on hosting server, IP 2.2.2.2

Server 2.2.2.2 calls SForce API for the application.  If that setting is on, it matches 1.1.1.1 with 2.2.2.2,

and gets an error. I want to make sure only User1 can run that app.  If I get a hold of the URL and User999 runs the web,

want to make sure User999 cant

For example, here's a test weblink, I generated 10 minutes ago (3:30PM Eastern Time)

when I send this to you, you can access it for up to 2 hours, executing an application

with my sessionID (bad)

http://64.14.91.171/EndecaSF/AccountDisplay.jsp?AccountId=001000000035Xxh&sessionID=.tG6xB0vOmqhgvtxA_Nhfy&apiPartnerServer40URL=https%3A%2F%2Fssl.salesforce.com%2Fservices%2FSoap%2Fu%2F4.0&AcLink=https%3A%2F%2Fssl.salesforce.com%2F001000000035Xxh&eneHost=localhost&enePort=8000&Type=FindAccount&Nr=FILTER(GNW)&baseUrl=https://ssl.salesforce.com/&sid=10318F85DA79

You see, you can access this external application using MY session ID â¬? which will expire after 2 hours. 

 In 2 hours, you can do a lot of damage

 

Message Edited by Joyce on 04-06-2005 12:40 PM

Destroyed SessionID.  Please don't post a session id.  We understand the point you are making, but posting session ids is not permitted.

Message Edited by DevAngel on 04-06-2005 12:42 PM

SuperfellSuperfell
But how did you get hold of the URL? in this case you explicitly chose to compromise your session by posting it to a discussion board, but in the app, only admins can setup WILs, and so the sessionId will only goto application that the admin trusts.

Without the external app re-verifying the user by asking them to login again, how does the external app know that User999 is User999 and not User1 ?
darozdaroz

SimonF wrote:
But how did you get hold of the URL? in this case you explicitly chose to compromise your session by posting it to a discussion board, but in the app, only admins can setup WILs, and so the sessionId will only goto application that the admin trusts.

Without the external app re-verifying the user by asking them to login again, how does the external app know that User999 is User999 and not User1 ?



The SessionID is visible to every user at login by viewing the frontdoor.jsp URL as it redirects...

Also, access to na1 is not restricted only to SSL access...

e.g. login at http://na1.salesforce.com/ (warning not SSL secured) and you'll get redirected to frontdoor.jsp, with session ID in plain sight and cleartext across the wire. It's also set as a cookie on your PC that gets sent with every request -- again, in the clear.
SuperfellSuperfell
but you have to actively do something to get non-SSL, by default (i.e. you start with the WSDL, or you start at http://www.salesforce.com), its always SSL. Only your sessionId is visaile as it goes through the frontdoor.jsp redirect.

As i continue to not understand the concern you have, perhaps you could outline what you think needs to change.
JoyceJoyce

I think it should check the IP address that is encoded in the sessionID to see if matches the caller's.  That will prevent malicious calls which can happen which didn't originate from the legitimate Salesforce user who clicked that WIL  

It just see like a security hole in Salesforce that anyone can access that application and run an application. 

So, my IP is encrypted in that sessionID (1.1.1.1).  That URL with the encrypted session can be called by someone else (if they get a hold of it but it is in the URL) when I call that URL, Salesforce should decrypt the sessionID, get the original IP, and check that 1.1.1.1 matches the sender's IP

Does that make sense?

 

SuperfellSuperfell
Yes, thats exactly what the "Lock sessions to the IP address from which they originated." option in security settings in the setup menu does.
darozdaroz

SimonF wrote:
but you have to actively do something to get non-SSL, by default (i.e. you start with the WSDL, or you start at http://www.salesforce.com), its always SSL. Only your sessionId is visaile as it goes through the frontdoor.jsp redirect.

As i continue to not understand the concern you have, perhaps you could outline what you think needs to change.



I think you may be confusing 'pointing it out' and 'concern'...

(Nearly) Every HTTP-based web application uses some sort of authentication. If not using the built-in HTTP auth many solutions fall back to a session-based cookie. It's just the next best thing, and more versitle.

I don't have a 'concern' with the Session ID -- It can (optionally) be restricted to the IP address that was used to generate it. Yes, I'm well aware that you have to make an effort to avoid the encryption used to secure the SessionID from wiretapping/sniffing.

I raise these points only because things are not 100%. It's possible to have a user get ahold of a SessionID w/o the use of a WIL. It's possible to also have it sent in the clear. It's certanly not normal, or I think, common.

The biggest potential failure of SessionID security has to do with locking it to a 'single' IP. When dealing with WILs not running on the client PC (or behind the same NAT) that lockdown won't work.

Most of the issues I raise, for imformational purposes, have no answer (having to use a sessionid and somehow get it to the client and avoid cross-site cookie setting problems). One does, WIL IP lockdown.

The current Session settings screen has a checkbox to restrict that Session to the IP that created it... If we could amend that to add "or one of the following IPs" or better still "one of the following IP ranges".

This would allow us to lock down sessions to the originating IP AND the IPs of our WIL partners. Thus even if the SessionID was leaked/stolen/sniffed etc it would be of virtually no use.

Finally Simon, in general the SessionID securtiy is quite adequate. Perfection is impossible, but even knowing all this before we signed our contract we still went ahead.
SuperfellSuperfell
The additonal IP ranges on the session checking is a good idea, you should log a case for it, so it gets on the feature request list.
JoyceJoyce

Simon, that setting doesn't do what I need.  It only locks down the IP of the HOSTED Server that is running the application.  The call is coming from where the application sits, not IP of the Salesforce user clicking on the WIL.

"Lock sessions to the IP address from which they originated" 

When I turn that setting on, no one can get to it because it's checking the IP of the application that is making the call to SForce, not the IP of the originating user who is clicking the WIL that calls the application sitting somewhere else.

I already tested this

By the way, thanks for being patient with this thread and answering these questions. 

benjasikbenjasik
Security is always a tradeoff. Make it tighter, and you lose some usability. Make the system too easy, and the system is too easy to break into.

We try to strike a balance. Strong security for everything, and super-strong if you want it. If you want to, you can lock down logins to a specific IP range, use our delegated authentication feature to pass one-time use SAML assertions for logins, lock down Sessions to IP ranges, use a private sharing model, etc. But you also need a system that's usable. You need to make the tradeoff with what you are comfortable with.

I think there are much greater risks than the sessionId being sniffed over 128-bit SSL. Social engineering is what concerns me the most.

The idea to have the sessionId only work for a range of IPs is interesting. Maybe we could piggyback on the login IP range feature we already have.

If anyone has other suggestions or concerns, please post them!