Tech Off Thread

8 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Securing high traffic sites without inproc

Back to Forum: Tech Off
  • User profile image
    itsnotabug

    i'm trying to get my head around a basic strategy for providing the best security for a high traffic site (as compared to the hardware it runs on) without using the built-in asp.net membership or session state. i'm a bit naive when it comes to hard core security so some opinions would be welcome Smiley

     

    bonus: no ssl. i realize this makes it very hard but i want to do the best i can.

     

    so far i'm thinking:

     

    1) sessionstate=off in web config

    2) "HttpOnly" non persisted, strongly encrypted cookie containing key/value pairs of UserId, UserName, UserLevel and IPaddress created on sucessful log in (authenticates against db)

    3) i create a page class that all other pages inherit from that performs a cookie sniff on init > if found, decrypt and check the ip address of the current httpcontext against the cookie value ipaddress > if match, set my current "user" object's UserId, UserName, and UserLevel to the vaues in the cookie and continue along with the rest of the page load.

     

    of course this is moot without ssl because anyone sniffing the network can intercept that cookie. hmmmm... any other holes in my plan?

     

  • User profile image
    W3bbo

    ASP.NET already does its own session cookie validation that protects against most session-hijacking attempts.

     

    Also, never use an IP address as a means of uniquely identifying a user: multiple users can share a single IP address, and single users can use several IP addresses (such as multi-homed setups, and roaming mobile/wireless connections).

     

    That said, why isn't SSL an option? If it's an internal application then you can use your Enterprise CA to generate a trusted certificate for free. If it's internet-facing you can get a well-trusted cert from $20 (from NameCheap, $30 from GoDaddy).

     

    What do you mean by "security" anyway? Securing the website from traffic sniffing? From brute-force attacks on the login page? SQL injection?

  • User profile image
    itsnotabug

    i'm aware of the problems with ip addresses. for me it would just be another layer to check... not a unique identifier. for single sessions i wouldn't imagine ip address changing unless the user was roaming on a mobile device and that wouldn't be a typical use case.

     

    i'm really interested in getting the most out of a server. i've read that any session state enabled would eat resources. so i'm wondering how people do it in the wild, unmanaged code world... without the built-in asp.net niceties. my naive assumption is that doing it that way (strongly encrypt the cookie, ensure httponly, check for conditions) would be less resource expensive than relying on asp.net server side session state tools.

     

    ssl would not be out of the question, but it's just not already in place. i'm guessing i can somehow get at the requested uri and do a quick redirect to the https: version. this would be optimal as it would lessen the potential for packet sniffing.

     

    htmlencode/decode should handle cross site scripting attacks, no?

     

    all my stored procedures are parameterized. i think that lessens that attack surface as well.

     

    i hadn't thought about brute force though. what's the common way to defend against that?

     

     

  • User profile image
    W3bbo

    i'm really interested in getting the most out of a server. i've read that any session state enabled would eat resources. so i'm wondering how people do it in the wild, unmanaged code world... without the built-in asp.net niceties. my naive assumption is that doing it that way (strongly encrypt the cookie, ensure httponly, check for conditions) would be less resource expensive than relying on asp.net server side session state tools.

     

    ssl would not be out of the question, but it's just not already in place. i'm guessing i can somehow get at the requested uri and do a quick redirect to the https: version. this would be optimal as it would lessen the potential for packet sniffing.

     

    That's how things are done.

     

    htmlencode/decode should handle cross site scripting attacks, no?

     

    Yep, but make sure you're consistent, and be especially careful with some of the System.Web.UI.WebControls that render content as-is without any encoding. Don't forget to UrlEncode as appropriate too.

     

    all my stored procedures are parameterized. i think that lessens that attack surface as well.

     

    You don't need stored procedures, you can use normal queries (since SQL Server 2005 there aren't really any performance gains), all that matters is that they're parameterised (or, more correctly, "prepared statements").

     

    i hadn't thought about brute force though. what's the common way to defend against that?

     

    For the most part, not worth worrying about. A big running joke in 'hacker' circles around the turn of the millenium were HTTP Brute-Forcers. The joke being that script-kiddies would think they were an actual serious tool for cracking open a Hotmail account, when in reality the huge limiting factor isn't just the literal years it takes to go through all possible combinations of characters, but the fact at the time most people were on 56K dial-up, each request for an individual password guess would take a few seconds to complete (even if doing them in parallel).

     

    However sustained dictionary attacks are a concern (because you never know how stupid your users are, so the attack might just work). The mitigation is simple: only allow a user (and maybe an IP address, but be careful) a limit of 3 or 5 attempts at entering a password unsuccessfully before locking an account and requiring a manual process to re-activate. ASP.NET's Membership system supports account locking, btw.

     

    Another avenue of attack to consider is at the database layer. It might be advisable to encrypt the database on-disk which helps if the hard-disk is physically compromised (assuming the keys are kept separate), one option is NTFS EFS which happens transparently of whatever DBMS you're using. MSSQL also supports per-database encryption which is more flexible.

     

    Most importantly is ensuring your users' data is appropriately encrypted and secured, starting with account passwords, but then so long as they're hashed and salted you should be safe if the data is leaked (though I'm sure your users will appreciate the loveley email spam they'll soon be getting). Assuming you're using ASP.NET Membership you'll be fine as it does this automatically.

  • User profile image
    blowdart

    , itsnotabug wrote

     

    htmlencode/decode should handle cross site scripting attacks, no?

     

     

    No. For example HtmlEncode (and even AntiXSS's HtmlEncode) leaves single apostrophes alone. Which is fine for Html, but if you get the encoding wrong and put that in an Html attribute ....

     

    You need to use the right encoding for the context of the output.

  • User profile image
    itsnotabug

    i came across an interesting read about scaling up one of the more popular high traffic sites (at least in its day): http://highscalability.com/myspace-architecture

    from what i gather, having your session not server dependent is the way to go as each request could be going to a different machine. also cache, cache, cache.

    sigh... i've got a lot to learn.

  • User profile image
    itsnotabug

    @blowdart: mmm.... this is an area of confusion as well. in webforms i think some of this is taken care for you.

    is this a good rule of thumb or am i totally misunderstanding the threat?... text (comments, blogs,etc) input by a user gets htmldecode on the way in.... htmlencode on the way out (to display to the user).

    links  input by a user gets urldecode on the way in... urlencode on the way out.

  • User profile image
    blowdart

    @itsnotabug: Some of - not all. It depends on the control, and the property. 

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.