Session Issue -- dotnet security

Jorge Matos
10/21/2004 6:33:03 AM

Shabam,

DotNet definitely supports this via the URLAuthorizatoin module. Read the
following informtion:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconaspnetauthorization.asp

hth
Jorge

[quoted text, click to view]

Jorge Matos
10/21/2004 9:37:07 AM

I missunderstood Shabams question, I thought it was just permissions based on
the URL path, I totally missed the GET arguments that were mentioned. Nicole
is right, you'd have to roll your own authorization for this and implementing
it in the business logic is probably your best bet. Another option would be
to create your own HTTP module or override the Authorize_Request() event in
the global.asax file to perform security checks on the GET parameters.

[quoted text, click to view]

Nicole Calinoiu
10/21/2004 11:58:12 AM

That level of permissions granularity is not provided by functionality build
into the .NET Framework, so you'll need to implement it yourself.

As for the best approach, that's a bit subjective. My own preference is for
screening for permissions when retrieving the data from the underlying data
store (usually a database). This way, any data that the user does not have
the right to view will not be returned from the data store and, without any
additional programming in the business or UI tiers, it will simply appear
that the requested data does not exist (assuming, of course, that the page
handles the case where no matching data is found <g>). Since I generally
prefer not to allow mis-users of an application to know that a piece of data
actually exists to which they have no rights, this outcome is fine by me,
but YMMV...

[quoted text, click to view]

Nicole Calinoiu
10/21/2004 12:02:16 PM

The built-in URL authorization module does not accomodate authorization
based on query string values. Even if it did, supplying it with the various
permitted values would be a maintenance nightmare.

[quoted text, click to view]

Shabam
10/21/2004 12:08:08 PM

[quoted text, click to view]

Shabam
10/21/2004 12:12:49 PM

[quoted text, click to view]

Checking for existence of data is good, but how about checking also when the
client attempts to submit data? For instance, if user A were somehow able
to pull up a configuration page for user B, (perhaps by copying user A's
html source code), then try to submit that. Shouldn't the application check
permissions again then?

Nicole Calinoiu
10/21/2004 4:07:42 PM

[quoted text, click to view]

Of course. You had mentioned GET requests which, by convention, do not
submit data for storage on the server, so I only covered reads. For writes,
you should probably also keep in mind that updates and additions may have
different permissions rules on at least some pages. In addition to read and
write operations, you might also need to consider deletions if your
application allows these.

Nicole Calinoiu
10/21/2004 4:13:09 PM

Centralizing this type of permissions assessment in either an HTTP module or
a request-level event isn't likely to be practical in most applications.
Aside from the potential for the permissions rules to take very different
forms on different pages, one would also need to consider that the same
query string parameter name may represent very different things across
pages.

For example, how many pages might use a query string parameter named "ID"?
The case statement for handling the different meaning of this named
parameter alone across pages would be a maintenance nightmare. It really
does make quite a bit more sense to handle such granular rules within the
pages themselves. When rules are shared by multiple pages, using a common
base page class would be convenient, but I can't imagine many applications
would share such rules across all pages.

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet security

dotnet security : Session Issue