 |
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
 Posted: Sat Oct 11, 2008 9:54 am
Can't login
|
No matter what I do the user/auth page dumps me back to the home page. I had no problems creating the account. I used the forgot password to reset my password, but that didn't seem to help. I have also turned off every security setting I can think of and still it does not work.
The only thing my security reported to me during testing, is that there is a "Content-Type: text/html" that refers to a .css file. It was resetting that to "Content-Type: text/css", turning that off didn't make a difference though.
I am using IE, the full version information is 6.0.2900.2180.xpsp_sp2_rtm.0408030-2158 |
|
|
|
|
Chiara
Site Admin
Joined: 29 Sep 2000
Posts: 389
Location: USA
|
Posted: Sat Oct 11, 2008 12:39 pm
|
Hmm. I wonder if Zugg messed something up while writing the backend last night. Or if our combination power outage/UPS failure corrupted something weird.
I can log in fine with my IE6 this morning.
I'll make sure he sees this before we go out today. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sat Oct 11, 2008 5:11 pm
|
I can't get it to fail with our IE6 here. Our full version is 6.0.2900.2180.xpsp_sp2_rtm.070227-2254, and I don't know if that's a more recent version or an older version. Maybe you can email me your login name and password privately and I'll try your direct account from here to see if it's a problem with your account data somehow.
Also, make sure your Cookies are enabled. You might even try deleting the cookies to let the site recreate them to see if that's a problem. If the session ID has gotten messed up somehow, then maybe that's the problem. If the site detects a problem with your session (like the cookie points to an expired session), then it redirects you to the home page and deletes the session. So maybe the cookie in the browser isn't getting updated.
This is definitely a problem that I need to understand and fix. It someone is having it with only a handful of testers, then I'd be afraid of making any sort of public release like this.
Finally, I'd need more detail on exactly which css file is tagged as text/html. In my header I only reference two CSS files for IE and both have type="text/css" set. One is master.css and the IE specific file is ie-master.css. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sat Oct 11, 2008 5:18 pm
|
A bit more information. This is really wierd. According to the database, your account was created on 2008-10-09 03:26:35 and last modified on 2008-10-09 03:38:01. And yet I see a last-login time of 2008-10-11 03:38:56. I don't see any record of any changed password, nor is there any un-used "recover password" link sitting in the database (the link that is given to recover a password is stored in a database table until used or expired). I also don't show any login failures for your account. So it looks like the site is properly logging you in.
Edited: I don't record any cookie/session errors in the database. Maybe I should. But this looks more and more like a cookie problem to me. If you send me the value of your cookie(s) for the www.slightlymorbid.com site, then I might learn more. Your cookie value is not encrypted...it's just a session id that points to an entry in our database. I can look at that session to see if it is messed up somehow. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sat Oct 11, 2008 5:22 pm
|
Just another addition. I just looked at the Session database and I don't see any session records for your user id at all. This is correct because sessions are only supposed to last for 30 minutes or so. So it doesn't matter what your cookie value is...it won't find any entry in the database, so it should create a new session and issue a new cookie. If your browser doesn't accept the cookie properly, then it will have a problem.
On Monday I'll play with cookies a bit more and see if I can come up with an error message to display on the screen if the cookie is not working properly. That might help. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Sun Oct 12, 2008 11:13 am
|
I couldn't find any cookies for www.slightlymorbid.com on my system. This is a log of me trying to log in this morning. The time on my system when I did this was 7:12 EST (GMT-5).
| Code: |
+++GET 364+++
POST /user/auth HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */*
Referer: http://www.slightlymorbid.com
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.slightlymorbid.com
Content-Length: 60
Pragma: no-cache
Connection: keep-alive
Browser reload detected...
Posting 60 bytes...
+++RESP 364+++
HTTP/1.1 302 Found
Date: Sun, 12 Oct 2008 10:48:43 GMT
Server: Apache/1.3.39 (Unix) PHP/4.4.8 mod_ssl/2.8.30 OpenSSL/0.9.7d
X-Powered-By: PHP/4.4.8
Set-Cookie: sm_session=e1c091247955a9d1e9c2539e1733ea3a; expires=Sun, 12 Oct 2008 11:18:43 GMT; path=/
Location: http://www.slightlymorbid.com/
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html
Connection stored: 364
+++CLOSE 364+++
Client Connection Reused: 1
BlockList 365: in Bypass, line 55
+++GET 365+++
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */*
Referer: http://www.slightlymorbid.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.slightlymorbid.com
Pragma: no-cache
Connection: keep-alive
Browser reload detected...
Connection Reused: 364->365
+++RESP 365+++
HTTP/1.1 200 OK
Date: Sun, 12 Oct 2008 10:48:44 GMT
Server: Apache/1.3.39 (Unix) PHP/4.4.8 mod_ssl/2.8.30 OpenSSL/0.9.7d
X-Powered-By: PHP/4.4.8
Set-Cookie: sm_session=39f530c1aa8b21f71341a492831b7cff; expires=Sun, 12 Oct 2008 11:18:44 GMT; path=/
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html
Connection stored: 365
+++CLOSE 365+++ |
You should notice the expiration time the server has given for the cookie (11:18:44 GMT = 6:18:44 EST) would make it already expired at the time I received it. My computers clock is off by about a half hour, and I turned off the automatic daylight savings time adjustment.
According to msdn.microsoft.com/en-us/library/aa384321(VS.85).aspx
| Quote: |
| If the expiration date is not set, the cookie expires after the Internet session ends. |
I will try adjusting my security to remove the cookie expiration date and see if that permits me to login. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Sun Oct 12, 2008 11:51 am
|
Getting rid of the "expires" part did it, I can finally play around with all the stuff that requires being logged in.
I will double check the css thing I mentioned later. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Oct 13, 2008 4:53 pm
|
If your computer clock is off by a half-hour, then I think that explains it. The session cookie is supposed to expire 30 minutes after it is created. I'll double-check the session code on this, and I guess I could make the session cookie last longer in the browser since it still expires in the actual session database. But I think the incorrect computer time is the cause.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Oct 14, 2008 12:00 am
|
I increased the session times to 1-hour today, so let me know if you still have any cookie problems. I still haven't added any detection code for browsers with cookies turned off, but that's on my list.
|
|
|
|
|
Tarn
GURU
Joined: 10 Oct 2000
Posts: 873
Location: USA
|
Posted: Tue Oct 14, 2008 12:33 am
|
| Zugg wrote: |
| I increased the session times to 1-hour today, so let me know if you still have any cookie problems. I still haven't added any detection code for browsers with cookies turned off, but that's on my list. |
I could see a user working for over an hour on their disaster message. Would they lose it on clicking submit and having an expired session?
-Tarn |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Oct 14, 2008 12:54 am
|
Unfortunately yes, unless their browser caches the contents of the message box like Firefox does.
We need feedback on the correct session timeout values. Unfortunately, lots of people just let their session tab lie around in their browser and don't remember to log off. And given the sensitive nature of this service, it's important to time-out those sessions.
But I also want it to be useable. An hour seems like a long time to work on a message to me, but I'd like to hear other thoughts. |
|
|
|
|
Tarn
GURU
Joined: 10 Oct 2000
Posts: 873
Location: USA
|
Posted: Tue Oct 14, 2008 1:29 am
|
| Zugg wrote: |
Unfortunately yes, unless their browser caches the contents of the message box like Firefox does.
...
But I also want it to be useable. An hour seems like a long time to work on a message to me, but I'd like to hear other thoughts.
|
An hour is a pretty long time, but it's not that uncommon for me to have something like a phone call and then lunch intervene while I'm in the middle of composing a post or email.
On this site, I lost a few posts before I figured out what was happening and started copying to the clipboard before hitting submit just in case things didn't work out.
Would it be possible to force the user to log back in but still keep the message that was posted in some way they could pull it out of a "Drafts" folder?
-Tarn |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Oct 14, 2008 2:26 am
|
Nope, that's impossible. It's a browser issue. If you haven't hit the submit button, then the message only exists in your browser window. And when your session times out, the cookie in the browser times out, so there is no way for the site to store the data into your session (because your session is gone).
If this was possible, then it would be easy for hackers to inject data into your session to be stored in the "Drafts" area, for example, because the server would have to accept your form data and store it even for an expired/invalid session.
Only the browser can save form data like this when a session expires. Firefox does this already so that you can click Back and recover the message that you entered.
Edited: Also, remember that we are talking about the Trusted Contact entering the email message, and in most cases I don't think a Trusted Contact is going to go away for a while in the middle of writing a death/crisis email. |
|
|
|
|
Tarn
GURU
Joined: 10 Oct 2000
Posts: 873
Location: USA
|
Posted: Tue Oct 14, 2008 3:41 am
|
| Zugg wrote: |
Nope, that's impossible. It's a browser issue. If you haven't hit the submit button, then the message only exists in your browser window. And when your session times out, the cookie in the browser times out, so there is no way for the site to store the data into your session (because your session is gone).
If this was possible, then it would be easy for hackers to inject data into your session to be stored in the "Drafts" area, for example, because the server would have to accept your form data and store it even for an expired/invalid session.
|
To me, the idea of an attacker putting something in the drafts folder is not a very scary proposition. If the composition form is over SSL, then the attacker would have to get access to the PC before the user logs out or closes the browser to accomplish even this minor annoyance.
Anyway, can you leave control of session expiry entirely on the server side by making the cookie long-lived but performing checks on the server side to control logouts and timeouts? (and possibly preserving a secondary session id in a hidden field)
| Quote: |
Edited: Also, remember that we are talking about the Trusted Contact entering the email message, and in most cases I don't think a Trusted Contact is going to go away for a while in the middle of writing a death/crisis email. |
I think an emotionally distraught user is more likely than your average forum poster to take a while to finish writing.
Well, I've said my piece: I'm a pretty atypical user, so I'm quite willing to accept the idea that it's not a problem.
-Tarn |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Oct 14, 2008 4:58 pm
|
Back to the original issue:
I have added some code to detect if Cookies are enabled or not. If they are disabled, or if there is a problem with the cookie expiring, then it will display a message at the top of the page saying that your session timed out and suggest that you check your cookie settings and date/time settings. So at least now it won't just send you back to the home page without any message. |
|
|
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Tue Oct 14, 2008 8:09 pm
|
| Zugg wrote: |
Back to the original issue:
I have added some code to detect if Cookies are enabled or not. If they are disabled, or if there is a problem with the cookie expiring, then it will display a message at the top of the page saying that your session timed out and suggest that you check your cookie settings and date/time settings. So at least now it won't just send you back to the home page without any message. |
Have you checked that you can not inject SQL statements using cookies? Using едц in the username field on the login seem to generate a database error:
| Quote: |
A Database Error Occurred
Error Number: 1267
Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='
SELECT * FROM (`users`) WHERE `username` = 'едц' LIMIT 1
|
You might want to hide showing such errors to not reveal your queries. From the query I can guess that your implementation retrieves the entire user row, then does an if-check on the password entered vs the one in the record. So to break in I guess you would have to actually inject a statement to modify the password of the user record. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Oct 14, 2008 9:32 pm
|
Thanks very much for finding that one Rorso. Looks like I created my database tables with the wrong character set value. I updated the database to properly use UTF8 and now the error seems to be fixed.
Once the system is debugged and fully in production, I will be hiding the SQL errors like this. But for now it's important to leave them on to find other problems with the system that I might have overlooked.
It shouldn't be possible to do any SQL injection, but if you find a way, let me know. The only cookie used is a unique session "id" value, so there is no real data stored in the cookie. All session data is in our database and the cookie is just the key to retrieve it. Sessions in the database are deleted after an hour, so it would be pretty impossible to "guess" an existing valid session_id to try and "hijack" a session. Since it also does IP and browser agent comparison, it really is next to impossible to do anything bad with the cookie data. |
|
|
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Tue Oct 14, 2008 10:06 pm
|
| Zugg wrote: |
It shouldn't be possible to do any SQL injection, but if you find a way, let me know. The only cookie used is a unique session "id" value, so there is no real data stored in the cookie. All session data is in our database and the cookie is just the key to retrieve it. Sessions in the database are deleted after an hour, so it would be pretty impossible to "guess" an existing valid session_id to try and "hijack" a session. Since it also does IP and browser agent comparison, it really is next to impossible to do anything bad with the cookie data. |
What I meant is if you retrieve the cookie id, then do something like:
SELECT * FROM table WHERE 'cookieid=$id'
Then could it be possible for an attacker to send a fake cookieid by using telnet, or editing his firefox cookie? E.g $id="'UPDATE users SET ...." |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Oct 14, 2008 11:31 pm
|
No, it's not something as simple as that. All of the input from the browser is secured and I don't just form the SQL statement directly like that. If they tried to send something like that, all of the special SQL characters get properly escaped, so it doesn't execute the hacked SQL. It would just fail to find a matching entry in the session table.
|
|
|
|
|
|
|
|
