> -----Original Message----- > From: Dan Allen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 24, 2004 7:59 AM > To: Struts Users Mailing List > Subject: preventing direct access to action > > > Normally we talk about preventing direct access to a JSP, but, in > contrast, have a question regarding direct access to an action. > Consider the following scenario: > > A portal application hosts several portlet modules. Each of the > modules is passed certain parameters from the portal when the user > selects that module. Some of these parameters determine the security > restrictions of the user (such as what components are visible to the > user). However, if the user changes one of these GET parameters, the > user could exploit greater access. Up to this point, a servlet filter > was checking that the "referer" field was non null. I know that this > form of security is highly discouraged (as it can be faked). How can > one be sure that the information passed from page to page can be > trusted?
If you're talking about as parameters, then you can't. If you're talking about session/request/application scoped variables then you can. However, it sounds like you can't do that exclusivley, but you can mix the two. So, your url would be something like http://blah/blah?key=someUniqueKeyThatIsNotTheSessionId that you use to pull the real parameters out of the session. Because the key is only for the session, and unique to that session you can be reasonably sure that the request is from the session that was intially authenticated. The vulnerability here is that someone is able to get a legitimate users session key, and the unique key while the session is still valid. If you're really paranoid, public key encryption of the unique key might even be possible, where the action that generates the link encrypts, and the action that performs the function decrypts the key before extracting from the session. Generating that key would be fairly easy, depending on your definition of easy.. I would take a hash of the sessionId + timestamp + relavantInfo[1] and use that. > > My guess is that the advice given is that the parameter must be > validated against the database for the current user, not just trusted. > In this case, the referer field is irrelevant. > > Dan > > -- [1]Relevant Info being maybe the action name, category or something else that would, in your case, identify the portal. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
