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.
Related
I have a public Apex app and I need a specific page to open in a different session. Not use the same session as the rest of the application.
Basically, I have in Chrome
Tab1 : Page A which requires authentication
Tab2 : Page B which is public
I need both pages to run in two different sessions.
At Page B level, I set "Rejoin Sessions" to Disabled
Now when I run the application, Page B opens in a new tab with a new session as expected, however, it kills the session of Page A and I'm redirected to login.
I'm using an Authentication Scheme with custumized session sharing:
Does anyone know how to solve that please ?
Thanks
Cheers,
The reason it kills your session from page A is because, on the client side, sessions are implemented using cookies. Both page A and page B are trying to use the same session cookie, with different session IDs, so whichever one writes to it more recently kills the other one.
If you view your cookies using your browser's F12 developer tools, you should see one like this:
Name Value Domain Path
ORA_WWV_APP_115305 ORA_WWV_FMN08hWNhlkjRDOIU_y yoursite.com /pls/apex (etc)
This is the session cookie for APP ID 115305, and the browser will send it along with every HTTP request to yoursite.com/pls/apex. Apex uses the Value to verify that you are allowed to have access to the session specified by the ID in your URL. If you modify either the cookie or the URL's session ID, your session is lost and Apex creates a new one for you.
So the Name + Domain + Path forms a sort of unique key here. You can only have one session for each unique Name + Domain + Path cookie.
I think the easiest solution here is to put your public page B in a separate Apex App. That way it'll have its own session cookie with a different Name.
(This is how the Oracle App Builder, which is also an Apex App, can have a separate session going at the same time without killing your app's session. Its cookies use a Name like ORA_WWV_USER_9872)
The alternatives are to use a different Domain or Path for page B, but that's trickier.
It looks like you've set up a custom Authentication Scheme, so I think your cookie would look like:
Name Value Domain Path
SESSIONCOOKIE ORA_WWV_FMN08hWNhlkjRDOIU_y yoursite.com / (etc)
But you're still using the same Authentication Scheme (and the same cookie) for both page A and page B, so they can't have separate sessions. This would be an instance where it might be nice if Oracle supported using a separate Authentication Scheme for each page, but they don't. This is what separate apps are for.
We are migrating from ColdFusion 8 to 10. Our application is having functionality written in .NET as well however the session is maintained in ColdFusion only.
Current architecture in ColdFusion 8 for .NET and CF integration:
Session is set when user logs in to the app (In CF). (We are using J2EE sessions.)
When a user clicks on a .NET link, Jsessionid,CFID and CFTOKEN are passed to .net page via url. Inside .net code the following steps are done to check session:
2a. Call a common function which will do a ColdFusion file request (chkSession.cfm) with jsessionid in url.
2b. chkSession.cfm will return session.UID if available else will return -1. Session.UID will be available if the jsessionid in url is valid.
2c. .NET page will be loaded if a valid UID is returned. User will be redirected to login page if -1 is returned.
Issue in CF 10:
In CF 10 , always we are getting -1. I read that as part of security enhancement in CF 10, we will not be able to recreate a ColdFusion session by passing cfide, cftoken, jsessionid in the url.
I would like to get your advice on what is the best way to make our .NET functionalties work in ColdFusion 10. Is there any better way to check ColdFusion session from .NET ?
One option I can think of is using a database. I looking forward to a solution that can be implemented quickly and is robust.
What I think would work would be to change your .Net client code to send over the JSessionID as a cookie value in its request. That way the functionality you have ought to work again.
It's worth noting that exposing the Session ID in URLs can expose you to certain security vulnerabilities, so it may be something you want to look at avoiding in future.
I have used the database approach you mention also. If you go this route, have the CF code insert a record using a GUID as an identifier and a timestamp for when the record was created. On the .Net side, look up the GUID and only accept the request if the timestamp is from less than X seconds ago, so you don't create a token which will authenticate you for a long time. X needs to be the max ammount of time you think it'll take a client to follow the redirect from CF to the .Net pages, so 2 is likely plenty.
You will want to delete used tokens and have a scheduled task to delete 'unused' tokens.
I did a little bit of Web Programming here and there but I never quite understood what's meant by the word Session.
I've googled a bit here and there, read the Wikipedia article, but could never quite grasp the meaning of it.
So, what's a Session?
Session is a way of persisting your information across multiple pages and requests. When you visit the login page of any site and you provide your username and password, you won't need to provide them again on subsequent pages.
This is done by attaching a session id, unique to your request, and is sent back and forth as you navigate pages.
Session Id could be stored in cookies (file on your system), in the URL as part of query string or in the database
A session is a place for storing data for a particular visitor of your site.
You can store data there that is also available on the next page request from that visitor. If some data is stored 'in the session', it means that the data is stored somewhere (possibly in the database of the server or in files) which the server can then use to construct the web page.
The visitor will receive a temporary cookie which contains a session id, an identifier which is used to associate that visitor with the session data that is stored on the web server.
The session id is sent to the server with each request and the server can lookup the stored session data (which can then be used to construct the web page).
It's the concept of keeping state around over an inherently stateless protocol like HTTP.
If you want to keep track of a logged-in user, for example, and maybe some data associated with that user, you could send that data between the server and the client each time, which of course would be terribly insecure. Or you could keep it in a session store on the server, for example a file or a database, and just exchange an identifier for the storage location between client and server. That's usually done via cookies these days, but could also be a parameter in the URL.
To make it simple:
If you first visit the site, the server gives the client an identifier. With this the server can identify a client across several request from the client to the server. The identifier is deleted after a preset time.
The combination of this identifier and the timeframe the identifier is valid, is called session.
Hope that helps. :-)
Session: An interaction between user & server, which has an ID associated with it. So that server can pin-point & serve the users according to their requests. Cookies are basically used for storing the session information because by default HTTP is state-less.
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!
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.