6

I'm into extend a authenticating service and like to ask about the security perspective of HttpContext.Current. Let say you have a authentication serve websites / wcf and such (where http is applicable). HttpContext.Current are used to store the session and other info in the Items array, no need passing credentials around throughout the session.

How safe are HttpContext and can it be misused and exploit security flaws? There are a a lot of posts and blogs that talk about "don't put session or System.Web into your business layers". Some just state "don't let the user know about your business layer". What would the user know and where are the border for a "business layer"? I.e. a business layer is solely a ground for web sites.

Where are the danger those folks predicate for and what can be done by a user that want to break the authentication? Are there "too easy" to develope bugs that make the system behave unexpected or give more access then mentioned?

Improve this question

2 Answers 2

Reset to default
5

"don't put session or System.Web into your business layers"

The primary reason for this is because it completely makes unit testing a nightmare. Your business layer is supposed to be completely separate from your web layer, you should be able to take that BLL and put it into a desktop app and have it run fine.

Being as HttpContext.Current is a collection of objects (Request, Response, Session, etc.) and they each have their own sources (Request headers, Response buffer, Session tied to ASP.NET Session ID cookie) that there isn't one universal answer for just the HttpContext.

However, Sessions do have some inherent issues, hijacking and session fixation is one of them, mainly caused by the inability to rotate session IDs on log-in, Micrsoft has declined to fix this, and you'll need to implement security around that (say, Webforms encryption of your session ID on log in is one example I briefly looked into (you'll want to research it more), or as we use, an authentication cookie that is tied to your session that is HTTPS only and rotates when required).

As for items like User and Identity, those depend on your authentication methods, usually handled by Webforms, but if you use a custom one again, security is up to you to use standard practices.

Improve this answer
6
  • Unit testing as a Nightmare. You mean that the testing relie on the existens of HttpContext? Like you have to surf the web and press buttons, to actually see the performance. That's a good reason. But it isn't really security related, other then that you mentioned (which are the case anyway in web entries). No flaw like break Auth.tickets and dig down in the logic?
    – Independent
    Commented Nov 13, 2011 at 9:03
  • I can see common cases where authentication 'ARE' in business layer and 'BUT' the layer are solely based on several web based authentication entries. As for me. A new authentication method does not have HttpContext but use business logic on same architectural level. That authentication entry can't be aware of the httpcontext even if I create a empty dummy, but httpcontext-objects are of course instantiated and handled by the system (another software process though)
    – Independent
    Commented Nov 13, 2011 at 9:06
  • "Unit testing as a Nightmare. You mean that the testing relie on the existens of HttpContext? Like you have to surf the web and press buttons, to actually see the performance." Not quite, the problem is a lot of HTTPContext is read only, sealed, and does a lot of logic internally that makes it hard to emulate in a unit test environment, abstracting away from all that prevents you from having to emulate the HTTPContext. Yeah the SoC isn't really security related, but it's why you'll see people recommending it.
    – StrangeWill
    Commented Nov 13, 2011 at 19:16
  • "No flaw like break Auth.tickets and dig down in the logic?" Well there was an exploit for web forms authentication a little bit ago, it's been fixed for now, but again that is based on your authentication method more than the way the HttpContext works, our custom authentication didn't have the exploit. That could lead to people elevating themselves to permissions they didn't have, but didn't give them any kind of remote execution abilities AFAIK, but again that is an exploit with the way WebForms Auth worked, not HttpContext.
    – StrangeWill
    Commented Nov 13, 2011 at 19:21
  • "I can see common cases where authentication 'ARE' in business layer and 'BUT' the layer are solely based on several web based authentication entries." I would say authentication should be a completely stand alone BLL that doesn't understand the underlying architecture above it (web based stuff), and to write your own custom Identity and Principal classes which will act as the interface between your web and BLL (if you were to do custom authentication).
    – StrangeWill
    Commented Nov 13, 2011 at 19:31
1

So, strictly speaking HttpContext.Currenty isn't technically a security boundary, as it's moreso just a thread boundary. With the right (or maybe wrong) placement of (server-side) code I could break into someone else's session.

As @StrangeWill pointed out with regard to not making session or anything related visible to the business layer it is moreso an architectural decision than a security decision.

Improve this answer
1
  • It appears to be an architectural question. Though you mention a point of "break into other sessions"?
    – Independent
    Commented Nov 13, 2011 at 9:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .