Facebook changes to make

Facebook made changes, yet again, to the privacy and data restriction usage.  You might want to check your settings to see what's new, and what's being shared.

Here's a good link to helping "reset" some of the changes Facebook made to your account.

I suspect my older post here, is now outdated.  I think some of the main ideas may still be relevant, just implementing them will take more steps.

Web form incident

I received a call today for an interesting incident. Bear in mind that the customer doesn't have an incident response policy, but I think that is going to change.  It seems a staff member received an "anonymous" email that, while technically not threatening, was certainly personal, mean and inappropriate.

The staff member forwarded me the email, with all relevant headers.  Even though there was a "from" address on the email, I realized that email addresses can be spoofed.  However, digging through the headers, I found an "admin"@company.subdomain email address.  Thinking the website might have been tampered with, I perused the web sites directory.  The site only has 20 or so static pages with one contact form.  Thinking contact form, I contacted the webmaster to see how the sub-domain actually worked.  After some digging, I learned that there is one script on the sub-domain that processes the contact form.  Bingo.  Looking at the contact form, email address is not required.  So, I tested sending the form without entering an email address; and I was able to replicate the incident.

I am now working with them to fix two issues:  1) There needs to be a documented incident response policy, such that the client is protected.  2) The website needs to address how to handle submissions without an email address.

The security ball is rolling, so hopefully good things can come of the incident.

And, while we may be able to get the IP of the person that submitted the form, I'm not sure what that will buy us.

Book Review: Seven Deadliest Web Applications by Mke Shema

I have been doing more and more testing of applications, and most of those applications have been web applications.  I think it is the nature of the beast.  Sure, sites have servers to manage their client workspace, and they handle mail.  But, if they have a web server and/or database server there's a good chance that they are hosting a web application.  Whether the organization "knows" it or not.

Last year I worked on the big application project where we had to test north of 80 applications in a very short time period.  My eyes were really opened during that project.  Since then, more and more, the sites we are going to have web applications.  I've taken it upon myself to improve my application (and by extension, web application) testing.  While the DoD has the Application Security and Development Checklist to guide them, actually testing the controls is not the easiest.  So, I've been trying to delve deeper into App testing.

I picked some books to start going through, and some of them are listed on my reading list.  The first one I've gotten to is Seven Deadliest Web Application Attacks by Mike Shema.  One of the reasons I picked this book is because the book just came out, literally, last week.  So, the book is current.  Mike is not a stranger to security or web applications and has a couple of books on web application security.

I have to say that I really liked the book.  Mike's style is easy to read and he's able to convey the knowledge and the points in each chapter concisely and in a matter that facilitates remembering the facts and putting them to use.  There are seven chapters that Mike focuses on:  Cross-site Scripting (XSS), Cross-site Request Forgery, Structured Query Language (SQL) Injection, Server Misconfiguration and Predictable Pages, Breaking Authentication Schemes, Logic Attacks, and Web of Distrust.

Each chapter goes into detail about the specific attack.  There are many good examples, code snippets, and current stories about relevant attacks in the real world.  Many of the attacks have analogies to reinforce the concept using non-technical language to put the attack in a different frame of mind.  The big three (XSS, CSRF, and SQLi) make up the first three chapters.  I admit, I come from more of a DBA background (from before my security days) so I didn't focus on SQLi as much.  However, I still picked up knowledge from the SQLi chapter.  We test for XSS a lot, and I was familiar with the information; but of the big three, I learned the most from the CSRF chapter.  Server Misconfiguration delves into attacks that are based on applications and servers that are not as hardened as they should be.  Breaking authentication discusses different methods to subvert and get around authentication.  I liked the chapter on logic attacks because it employed the use of thinking outside the box.  These attacks were not the result of fundamental coding errors; they were errors in the way the application was designed.  Finally, the last chapter (Web of Distrust) compiled a bunch of different attacks.  Malware, scareware, referer attacks, html, and DNS all were given sections.

Each chapter starts out by defining the specific attack; what it is composed of, how it works, and how to employ it.  The chapter also devotes a section to employing countermeasures and how to mitigate the specific attacks.  Finally, a summary puts it all together.  I really liked the small sections titled "Epic Fail" where a specific attack is given a real-world example.  Also, there are many URLs given for tools that are discussed and for points for further information.  There are a couple of tools that I'm actively researching and looking to use that I learned about from the book.

The book is not a cookbook or a how-to on performing the attacks.  While lines of code are given as examples, there are not step-by-step instructions on how to successfully exploit the attack.  And that was fine for me; that wasn't my goal.  There are other books out there; in fact, there are whole books devoted to some of the chapters.  So, if you are looking for step-by-step instructions, this book is not for you.

I rate the book very highly and would recommend it to anyone wanting a good overview and jumping off point for the seven major web application attacks.  I've brought the book into my office and hope others will get as much out of it as I have.  You will not go wrong in reading the book if you want to learn what the major attacks are, how they work, and some mitigations to lessening the threat of these attacks.