OK Just for completeness for anyone reading this regarding "how do sessions
work", here is my summary (apologies that this is a somewhat App Engine
biased response, and these steps are only designed for a native GWT/GAE
installation, I cannot comment on any other framework)
1. App Engine does not by default have sessions turned on (you have to
add the following to your 'appengine.web.xml' file)
- <sessions-enabled>true</sessions-enabled>
2. To Set a default timeout for App Engine sessions you need to add
the following to your 'web.xml' file
- <session-config>
<session-timeout>60</session-timeout> <!-- minutes of inactivity -->
</session-config>
3. on your server you can use the following to 'get' your current
session:
- HttpSession session = this.getThreadLocalRequest().getSession();
4. Then once you have confirmed that the user has performed a successful
login you do something like the following:
- session.setAttribute("authenticatedUserName", username);
5. Then later when your server recieves any request for data you include
the following code:
- if
(this.getThreadLocalRequest().getSession().getAttribute("authenticatedUserName")
!= null)
{
//get the data and send it back
}
else
{
//send back an error message stating that the session has
timed out
}
6. You can manually invalidate the session (eg if the user clicks logout)
by using:
- this.getThreadLocalRequest().getSession().invalidate();
7. Each time the Client makes an RPC call to the server (Assuming the
Session is still valid (ie not timed out)) then the Session is automatically
refreshed with a timeout set to whatever you set above in the web.xml file
8. On the Client Side you can use the following line to establish the
session ID (if cookies are enabled):
- String jSessionId=Cookies.getCookie("JSESSIONID");
9. You should however probably take care of what happens if Cookies are
not enabled, you can test this with:
- if (Cookies.isCookieEnabled()) {/*deal with someone who has cookies
disabled*/}
10. However, this is relatively meaningless until you check with the
server that the session is actually still "valid" as the session validity is
ALWAYS controlled by the server. There is no real way to confirm on the
client side that the user is logged in and still had a valid session until
you connect to the server and ask for some data. However, you could set a
flag on the client for efficiency to determine for instance which
buttons/popups are enabled/available after a user is logged in rather than
having to keep asking the server.
Incidentally, does anyone know how to turn off cookies, if you dont actually
want to use them, and yet still use sessions on the server? Id rather not
have the prompt appear that says that my site needs cookies enabled,
especially if im not actually using them!!
Hope this helps some people reading this, feel free to comment or correct if
ive done anything wrong!
John
On 28 April 2010 00:55, John Denley <[email protected]> wrote:
> OK, I think Im getting somewhere with all this, thanks so much for your
> input Sri!
>
> Essentially all I need is an interim solution until GAE supports SSL. We
> are actually not going to be storing data thats likely to be particularly
> exciting for any hacker, the best they can hope for is a list of addresses
> of people who use any one hairdresser in any one town!
>
> Regarding the "5 points" (Which I think we can now cut down to just one
> (the use of sessions) going forward!)
>
> 1. I understand that any kind of encryption on the client is
> effectively pointless without SSL, but its always going to be better than
> nothing! A bit like saying that hding your front door key under a rock in
> your neighbours front garden is no different to leaving it in your front
> door........
> 2. I figured TLS was something like SSL, either way its not on GAE yet,
> so I cant use it yet!
> 3. My passwords are being salted and hashed
> (jBcrypt<http://www.mindrot.org/projects/jBCrypt/>)
> before being stored.
> 4. & 5. Still not sure i get how sessions really work. Ill keep reading
> and trying to figure it out. But surely at some point I still need to send
> the session ID from the server to the client right? As far as I can tell so
> far, the session ID is generated on the server, so the right thing to do it
> set a timeout on that sessionID and "touch" it every time the user makes a
> call to the server, making sure that the sessionID has not timed out. There
> are mentions in various places that you should "refresh/regenerate" the
> sessionID on a regular basis during a logged in session, to keep it
> fresh.....
>
>
> On 27 April 2010 10:16, Sripathi Krishnan <[email protected]>wrote:
>
>> If you can recommend a security framework that works with App Engine and
>>> custom URL's without SSL/HTTPS and has really good documentsation for
>>> complete dummies then please do let me know....
>>>
>> As far as I know, the above is impossible. You cannot have security
>> without ssl. You cannot have a custom domain *and* ssl *and* GAE (because
>> it is prohibitively expensive for google). And you have already starred the
>> GAE
>> issue that speaks about
>> it<http://code.google.com/p/googleappengine/issues/detail?id=792>,
>> so there really isn't anything new for me to add.
>> If you cannot use google's authentication, and if you can't use any of the
>> (not-so-secure) workarounds described in that issue, I am afraid there is no
>> way you can use GAE. I'd recommend discussing this in GAE discussion thread
>> to get ideas from people. Either that, or just wait till GAE starts
>> supporting SSL.
>>
>> Additional responses to your comments
>>
>> 1. It doesn't matter what encryption method you use on client side; it
>> may be the most secure algo on earth. The problem is with the key
>> management. JS code needs the key to encrypt. And if it is in the JS code,
>> an attacker will always be able to get it. Ofuscation is just a very minor
>> hurdle, its easy to read through it.
>> 2. TLS is transport layer
>> security<http://en.wikipedia.org/wiki/Transport_Layer_Security>,
>> which is essentially the new SSL.
>> 3. On the server side as well - you should NOT encrypt passwords.
>> Encryption means there is a way to decrypt and recover the password. If
>> you
>> can decrypt it, an attacker will find a way as well. The recommended way
>> to
>> store passwords is to Salt and Hash
>> them<http://www.aspheute.com/english/20040105.asp>
>> .
>> 4. Sessions can loosely be described as
>> 'per-user-server-side-hashmap'. The server automatically creates a cookie
>> 'jsessionid' to track the user. So when you call request.getSession(), the
>> container gets the session id from the jsessionid cookie and then gets the
>> state corresponding to that sessionid. You should read more about this in
>> the j2ee tutorial.
>> 5. I'd recommend OWASPs guide to session
>> management<http://www.owasp.org/index.php/Session_Management>.
>> If you are interested in application security, OWASP is the best place to
>> learn.
>>
>>
>> --Sri
>>
>>
>> On 27 April 2010 12:54, John Denley <[email protected]> wrote:
>>
>>> Awesome response SRI, and with a bit of luck this will help all those
>>> hundreds of people on here who are struggling with how to implement decent
>>> security.
>>>
>>> Ive spent months wrestling with security, after finding out that Google
>>> accounts doesnt have a good enough API for use with GWT/GAE.....and that GAE
>>> doesnt support SSL/HTTPS for custom URLs (eg in my case www.ucanzoom.com
>>> )
>>>
>>> What struck me immediately is how easy it was for you to figure out what
>>> my client side code was doing, esp given that GWT should be obfuscating the
>>> code, which I thought would me making it pretty hard to actually "read my
>>> source code"...
>>>
>>> Ill address your points individually and I would very much appreciate any
>>> further feedback you are willing to give.
>>>
>>>
>>> 1. The client side encryption is just trying to make it as hard as
>>> possible for "people like you";) to crack my password, ive had loads of
>>> people say "theres no point doing client side encryption", but my
>>> feeling is
>>> that you have to do SOMETHING on the client side, even if it does only
>>> take
>>> a determined hacker half an hour to figure it out. At least im forcing
>>> someone to consider whether or not its really worthwhile bothering to
>>> spend
>>> that time trying to crack my encryption. Even the fact that you have
>>> referred to it as "some kind of encryption" makes me smile, as you are
>>> right
>>> in that I have created what i think is a pretty tough encryption. Id be
>>> interested to hear what kinds of methods a determined hacker might use to
>>> crack it, as Im fairly happy that the only way to actually do that would
>>> be
>>> to examine the source code. I dont think that any kind of brute force
>>> will
>>> succeed, but Im reasonbly OK if brute force will work, as stated earlier
>>> in
>>> this response! Im not happy that you can find the "secret key" id
>>> forgotten
>>> to hide that... Ill get onto that ;)
>>> 2. Ive never heard of TLS, but SSL is not currently available for
>>> custom URLs on Google App Engine, which is why I cant use it. Extracting
>>> the
>>> password is something that worries me, however I am somewhat relying on
>>> the
>>> sessionID to provide a unique "connection" once the user has just logged
>>> in
>>> once (see some comments below on this)
>>> 3. I am using a well recognised encryption algorithm on the server
>>> side to actually store the passwords in Google App Engine Big table
>>> (although Im reasonbly happy about the fact that Google datastore is
>>> pretty
>>> secure in its own right)
>>> 4. I dont really understand session ID's and have not been able to
>>> find a simple explaination anywhere on the web as to how they work. Im
>>> not
>>> actually planning on using cookies initially because of the potential
>>> security issue. Is a session cookie automatically created? does it store
>>> the
>>> same sessionID as the server?
>>> 5. how does the server know if im logged in or not? Actually, from
>>> point 4, Im just guessing that you could store the session ID with a
>>> timeout. Is that how it should be done? Checking it on the client side
>>> is an
>>> efficiency thing, no point in doing an RPC call if the client side knows
>>> for
>>> sure if the session is not logged in. The client side check is more of a
>>> check that your logged out rather than a check that you are logged in....
>>>
>>> If you can recommend a security framework that works with App Engine and
>>> custom URL's without SSL/HTTPS and has really good documentsation for
>>> complete dummies then please do let me know....
>>>
>>> Thank you SOO much for your input Sri, its really great to have had even
>>> the feedback you have given me so far!
>>>
>>> John
>>>
>>> On 27 April 2010 04:46, Sripathi Krishnan <[email protected]>wrote:
>>>
>>>>
>>>> 1. You are doing some kind of encryption of passwords on the client
>>>> side. Its a big mistake. Its easy to figure out how its being
>>>> encrypted/hashed. In your case, the secret key is
>>>>
>>>> L87Y9*(yOFDMrsn};W/.XEPvSt]{uwl~,ozi34jQmT:@Rd)CZae2k|=6^I_+AG-[x01HBNpqUb?cJKV5fgh.
>>>> The exact algorithm used for encryption is also extractable, just needs
>>>> half
>>>> an hour of determination.
>>>> 2. Not using SSL/TLS is another big mistake. It is trivial for
>>>> anybody to see the traffic an extract the password. Your custom password
>>>> encryption algo (in 1 above) is not going to help at all.
>>>> 3. I can't tell how you are storing passwords on the server side,
>>>> but you must salt and hash your passwords. They must not be stored in a
>>>> recoverable form. Also, use a strong hash function (SHA-1, for
>>>> example). MD5
>>>> is broken, don't use it. And please do not create your own hash
>>>> function,
>>>> its not worth it.
>>>> 4. Why do you have a RPC method getSessionID()? You don't need the
>>>> sessionid in client side code. Just stick to the default session id that
>>>> your application server provides. If you want to read the session
>>>> identifier, pick it up from the cookie
>>>> 5. I see there is a javascript check to see if the user is logged in
>>>> or not. I hope you are doing it on the server side as well... Its
>>>> useless to
>>>> do the check on client side.
>>>>
>>>> To summarize - please don't build authentication/authorization yourself.
>>>> Its far easier and secure to use a framework. Once you get the basics
>>>> right,
>>>> go through the Security for GWT
>>>> paper<http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications>for
>>>> additional information.
>>>>
>>>> --Sri
>>>>
>>>>
>>>>
>>>> On 27 April 2010 07:08, John V Denley <[email protected]>wrote:
>>>>
>>>>> Ive just created an application as part of a learning experience about
>>>>> security with GWT/GAE
>>>>>
>>>>> This has prooved necessary after discovering that using google account
>>>>> logins is unacceptably complex for our potential clients, and as there
>>>>> are no plans within google for a tighter integration with GWT/GAE I
>>>>> have had to do it myself.
>>>>>
>>>>> I know that I am not using SSL/HTTPS and that probably means im very
>>>>> vulnerable to man in the middle (eve) attacks? but I dont know how to
>>>>> test exactly HOW easy it is to crack, or if its even anything i reall
>>>>> need to worry about!
>>>>>
>>>>> www.ucanzoom.appspot.com
>>>>>
>>>>> Happy to hear any feedback
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Google Web Toolkit" group.
>>>>> To post to this group, send email to
>>>>> [email protected].
>>>>> To unsubscribe from this group, send email to
>>>>> [email protected]<google-web-toolkit%[email protected]>
>>>>> .
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Google Web Toolkit" group.
>>>> To post to this group, send email to
>>>> [email protected].
>>>> To unsubscribe from this group, send email to
>>>> [email protected]<google-web-toolkit%[email protected]>
>>>> .
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Google Web Toolkit" group.
>>> To post to this group, send email to [email protected]
>>> .
>>> To unsubscribe from this group, send email to
>>> [email protected]<google-web-toolkit%[email protected]>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<google-web-toolkit%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
