Classic ASP creates cookies with name something like ASPSESSIONIDSSDSQQCR where suffix after "ASPSESSIONID" is different.
If you work for some time with application browser keeps storing all previous session cookies (could be 10 cookies or more), so there is no way to understand which cookie is for the current session
I know there is a way to get current SessionID
Session.SessionID
but how can I get a cookie value as well?
I'm just trying to create authentication solution for ASP.NET which is just addon for Main Classic ASP application.
In that design main application creates record in database with current Classic ASP cookie value and after that when user tries to access ASP.NET part, it just takes all "ASPSESSIONIDSSD+XXXXX" cookies in request and verifies which one of them is still valid by looking for initial record in database. If valid session found then it should initiate ASP.NET session....
I don't think you can get Classic ASP's Session ID cookie from ASP.NET. The Classic ASP session cookie has crypto applied to prevent your clients from tinkering with it. Unfortunately, this also prevents your .NET code from tinkering with the session cookie.
The easiest thing I can think of is to set an additional cookie in your Classic ASP code. Rather than storing the Classic Session ID in your database, store some other key, like a GUID. Then send a session cookie to the browser with the key.
Response.Cookies("SessionKey") = GeneratedGuid
You can then read the SessionKey cookie in .NET and lookup its value from the database.
Related
I am trying to understand, how exactly the session management mechanism in a stateless web application works. Currently I am using Play Framework but I think the mechanism should be the same for all of the stateless web frameworks
this is from the documentation of play framework: (link)
It’s important to understand that Session and Flash data are not stored by the server but are added to each subsequent HTTP request, using the cookie mechanism
and
Of course, cookie values are signed with a secret key so the client can’t modify the cookie data (or it will be invalidated).
Now my question is, if the server does not save anything about a session id, how does it authenticate a session coming from a client?!
I did a lot of searching, but I couldn't find out, how the session management on the server side really works.
Now my question is, if the server does not save anything about a
session id, how does it authenticate a session coming from a client?
What play does is it signs your session data through a key say KEY(Its the application.secret that you set in application.conf) and produce a alphanumeric data. Then it attaches both data and encrypted data to cookie and sends it back
ENCRYPTED DATA= 5d9857e8a41f94ecb2e4e957cd3ab4f263cfbdea
DATA = userEmail=sil#st.com&userName=silentprogrammer
If you Inspect the cookie(Right click on browser->Inspect element->Application->Cookie->Your url) in the browser of your running application you can see something like
"5d9857e8a41f94ecb2e4e957cd3ab4f263cfbdea-userEmail=sil#st.com&userName=silentprogrammer"
For each request it gets the data part(userEmail=sil#st.com&userName=silentprogrammer) signs the data again from the KEY and checks it to the alphanumeric data coming from request i.e. 5d9857e8a41f94ecb2e4e957cd3ab4f263cfbdea if the both are equal(if data and encryption key is same) the session is confirmed otherwise session expire. You can confirm this by changing the data part from cookie in browser and sending the request again the session will not exist.
This is what I have observed
I'm working with an old ASP.NET application which has lots of lousy code.
I have been mostly a winform developer and my knowledge of webforms is still limited.
However looking at code the way the developer tried to pass information to other pages sound invalid to me.
Here is a typical way he passes info from one page to other page:
Response.Redirect("ABC.aspx?SessionID=08F7DCF3D6984EC984F6580A4EC7E9C2&CID=" _
& e.Item.Cells(iColClientID).Text & "", True)
Then on other pages he uses Request.QueryString to get the data back:
Request.QueryString
My question is why in the world he needs to also pass a Hardcoded SessionID=08F7DCF3D6984EC984F6580A4EC7E9C2 in the query string.
Web.config shows :
<sessionState mode="InProc" cookieless="false" timeout="30"/>
So if session is using cookies why send session id?
To me code is written by an amature developer. Please provide your feedback.
Unless he uses the SessionID parameter for something else -some other obscure logic in there that relies on it being present in the QueryString-, there's no reason to put a SessionID in the query string at all. With or without cookies enabled how to get the SessionID should be transparent to you and it suffices to do:
var sessionID = Session.SessionID;
Some relevant documentation from MSDN regarding cookieless sessions (which is not the case here according to the Web.config you showed):
ASP.NET maintains cookieless session state by automatically inserting
a unique session ID into the page's URL. For example, the following
URL has been modified by ASP.NET to include the unique session ID
lit3py55t21z5v55vlm25s55:
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx
When ASP.NET sends a page to the browser, it modifies any links in the
page that use an application-relative path by embedding a session ID
value in the links. (Links with absolute paths are not modified.)
Session state is maintained as long as the user clicks links that have
been modified in this manner. However, if the client rewrites a URL
that is supplied by the application, ASP.NET may not be able to
resolve the session ID and associate the request with an existing
session. In that case, a new session is started for the request.
I'm attempting to share session data between my PHP site and an ASP site and as I have access to the ASP site's MSSQL database and some of the ASP session data appears to be in a database table I was hoping I could grab the session id from the session cookie and go from there.
I don't know a lot about ASP but from what I've read it takes the session id, encrypts it and produces a session cookie name / value. Does anyone know how I can decrypt that cookie and get the session id back?
Or is there a better way of doing this baring in mind although I have database access I'm not really able to make code changes.
You can access the sessionID via the Session object
<%
Response.Write(Session.SessionID)
%>
Note though that the session ID is only valid for a user's current session and is not persistent. i.e. if there's no activity for 20min a new session is created for the user if they return. I'd use regular cookies myself and pass a hash around.
How can I increase the security of my sessions?
$this->session->userdata('userid')
I've been throwing this little bad boy around for my ajax calls. Some cases I haven't. Then I was like, is this really secure using id from the DOM? what if the DOM is changed to hack user accounts data? So then I was like I guess anytime a user is doing something relating to their id, only sessions should be referenced. Am I right?
Referenced like so:
$this->some_model->do_data_stuff($dataId, $this->session->userdata('userid'));
Then I read this:
While the session data array stored in the user's cookie contains a
Session ID, unless you store session data in a database there is no
way to validate it. For some applications that require little or no
security, session ID validation may not be needed, but if your
application requires security, validation is mandatory. Otherwise, an
old session could be restored by a user modifying their cookies.
http://codeigniter.com/user_guide/libraries/sessions.html
I'm not going to be storing financial data but I don't want any data on my site corrupted ever. Does SO use session validation? How much overhead will this validation cost? How would a session be hacked? What are some things to look out for with session security?
Using CodeIgniter sessions with database is going to be fairly secure. You just don't have to trust the input that the user gives. Even if you are using AJAX, the CodeIgniter session will work just like any standard call, so the same security goes on.
What happens with the CodeIgniter session is that the server stores the cookie, and every time the user does an action that would change the content of the cookie, it is first compared to the previous cookie.
If the user changes the content of the session cookie in the browser, CodeIgniter will notice on the next server call, and create a new session for the user, basically logging him out.
CodeIgniter doesn't really need the data stored in the cookie in the user's browser, and as long as you're using
$this->session->userdata('userid');
you're going to get trusted server-side data. The user can't change that. Furthermore, the cookie can be encrypted, and you should have it encrypted. Just look in config.php of CodeIgniter.
There are several other protections around the session data: the short refresh timeout (usually 300 seconds), it checks if the IP changed, and if the browser changed. In other words, in the worst case scenario, the only way to spoof the session data is by having the same version of the browser, having the same IP, getting direct access to the computer to copy/paste the cookie, and getting this done within 5 minutes.
So, watch out for the guy sitting beside you!
What's an elegant way in Classic ASP to check if session cookies are enabled in a user's browser using server side code (because javascript might be disabled as well).
I have a solution of my own but it looks ugly as hell.
#James - that doesn't differentiate between setting a session cookie and a general purpose cookie though (IE lets you differentiate between First Party, Session Cookies and Third Party, but I see with Firefox they only differentiate between First Party and Third Party)? I'm setting a session value in a login page then doing a Response.Redirect kinda thing and checking to see if the session value is still valid.
Unless you specify an expiry on the cookie it will be a session cookie. The term session is a bit overloaded in HTTP. When the IE dialog refers to a session cookie it means any cookie that is only stored in process memory and not persisted to disk, therefore only lives for the duration of the process (the session). Start another IExplore.exe process and you have another session which will not have the values of any previous or extant session cookies.
You are correct though that you can test whether even session level cookies are being blocked by just storing a value in the session object and testing for its presence on a redirect.
Well, the "ugly as hell" method we used, was to set a cookie and redirect to a new page. In the code for the new page, see if the cookie was set. Since the only way to get to the second page is to be redirected there when the cookie is set, it's presence or absence should tell the state of the browser.