Friday, October 16, 2009

Internet Safety for Parents

A friend asked me about Internet safety including how parents can protect children from the nasty stuff that's out there. I replied by describing what I do at home. It's probably not the perfect system, but it seems to work for me.

If you know nothing about Internet safety, start by visiting the resources listed here. Educate yourself about Internet dangers and the kinds of protection available.

In terms of filtering, I recommend using the Windows Vista built-in parental controls. You can select age-appropriate access level, define time restrictions, view logs of sites visited, etc. Each user must have their own login on Vista (no sharing accounts!). If you're not using Vista, please think seriously about upgrading. The parental controls feature alone is worth the money. However, at this point in time you should probably upgrade to Windows 7 since its release date is near. I assume it has the same or even better parental controls.

Defense in depth applies in protecting children too. So for better protection, I also recommend using BlueCoat's K9 Web Protection (available for free). It is not as flexible (all users have the same filter level), but it catches some stuff that Vista doesn't. If you are currently stuck on Windows XP, use K9 at least. Just remember it is not perfect.

Finally, if you don't want a hacker opening a reverse shell and taking over your computer, make sure you check for software updates at least weekly! Or, have it done automatically if possible. These updates should include not just Windows and Anti-Virus software, but also Internet Explorer, Adobe Reader, Flash Player, Firefox, Thunderbird, Java, iTunes, etc.

Read more...

Friday, October 9, 2009

ColdFusion Session Fixation

I usually see session fixation vulnerabilities with Java web applications. Just recently I found a ColdFusion application vulnerable to session fixation. This nasty security hole greatly increases the risk that legitimate sessions will be hijacked. Both HP WebInspect and Burp Pro's active scanner failed to find this vulnerability. Testing for session fixation is quite easy to do, so I ran a quick test for it manually, and I'm very glad I did.

When testing for session fixation, I like to use two different browsers: IE and Firefox. If the login page for an application is https://someapp.com/login, my test for session fixation consists of the following steps:

    1. Launch Firefox and navigate directly to the login page.

    2. Inspect the cookie(s) assigned by the application. For a Java web app, a JSESSIONID cookie is normally set. In the case of ColdFusion, CFID and CFTOKEN cookies are typically set.

    3. Copy the session ID from the cookie.

    4. Construct a special URL that contains the session ID.
    For Java, it looks like this:
    https://someapp.com/login.jsp;jsessionid=[sessid]
    For CF, it looks like this:
    https://someapp.com/login.cfm?cfid=[cfid]&cftoken=[cftoken]

    5. Open IE and configure it to run through a proxy (Burp, Paros, Fiddler2, etc.).

    6. Paste the special URL into the IE address bar and hit Enter (this step simulates a victim clicking on a link in an email or Internet post).

    7. Observe the HTTP response from the server. Is there a "Set-Cookie" header? If so, what is the session ID being set? You have a problem if it's the same value that appears in the URL. On the other hand, you're probably okay if the value is different.
The ColdFusion site I tested was handling the situation even more poorly than usual. It was not necessary to visit the site initially to obtain legitimate session IDs from the server, so steps 1-3 above weren't required. An attacker could make up *any* 6 digit value for "cfid" and *any* 8 digit value for "cftoken", embed the made-up values in the malicious URL, and the application happily accepted them. The server responded by assigning CFID and CFTOKEN cookies based on the made-up values as illustrated below.

The URL of the request was:
https://someapp.com/login.cfm?cfid=999555&cftoken=29292929

The HTTP response contained the following headers:
Set-Cookie: CFID=999555; path=/; Secure
Set-Cookie: CFTOKEN=29292929; path=/; Secure

Read more...

Saturday, October 3, 2009

Who Has the Answers to Your Security Questions?

I'm back after a summer that was crazy busy for me. Recently, I had two eye-opening occurrences where other people viewed the answers to my personal security questions - you know, those questions that web sites ask in case you forget your password. These incidents weren't security breaches, just normal business processes that appear to be more prevalent than I thought.

In the first incident, I got a new cell phone for my daughter at a retail store of one of the major providers. I gave the clerk my cell number so he could look up my account and he then asked for my "PIN". I didn't know it. I knew my password for their site, but that's not what he wanted (I wouldn't have told him anyway). Since I didn't know my PIN, the clerk followed up by asking me "What's the model of your first car?". Whoa. I proceeded to answer the question. He looked at his monitor and said "okay, good".

The other incident involved Vanguard again. I got locked out of their site (not just unrecognized like last time). The darn thing wouldn't even allow me to answer my security questions. Forced to call Vanguard customer service, I explained to the CSR that I was completely locked out. Wouldn't you know the CSR simply asked me to answer two of my security questions? I provided the correct answers, and he immediately unlocked my account allowing me to log in again.

Moral to the story: These answers are not simply being used programmatically or being treated as confidential data. Realize that the answers to your personal security questions could be viewed by other people in many cases.

Read more...

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP