Science-Blogs@2007 Weblog Awards - Failures and Countermeasures : 5ubliminal's TellinYa

Make sure you first read the other related first post : Anatomy of a break-in at WebLogAwards 2007 before this. At the end of that one you find a link here …

Smoke-wall Security at WebLog Awards 2007

After disecting the break-in at WebLogAwards 2007 now I will show you how they failed to protect themselves and how they can do it better next year.

Before everything I want you to understand that if you don't secure your blog properly it's really difficult to change the figures afterwards. Doubt will always be there so do a good job upfront or shut-it and swallow. Changing the results will ruin your reputation.

How their security worked!

Any decent security has to have at least two layers: server-side and client-side. WLA had only client-side. Let me explain you what client-side and server-side security is all about.

Client-Side and Server-Side security!

It's as unsafe as it gets against any more advanced user. For example. Let's say you make a Control Panel where more then one user can login and edit articles. Each article has an unique article ID. Let's say article 1,3,7 belongs to user 1 and 2,4,5,6 belong to user 2.

When User 1 accesses the Control Panel he gets a list of link pointing like this: edit?id=1 , edit?id=3 , edit?id=7 . The User 2 sees the other articles that belong to him in the links. So to edit an article user 1 accesses : edit?id=1 ! OK! Not really …

What is the User 1 decides to manually change the article ID to 6 which belong to User 2. If you don't do server-side sanity checks on data you go down. By just providing links to User 1's own content you actually just do Client-Side security. But, if you dont' do Server-Side checks of Article owner before edits, anyone can change anyone's stuff.

This is the difference between client-side and server-side security and at all times both have to be available.

Where did weblog awards mess-up?

On every vote they script locked the Flash from voting based on IP probably. But they never checked incoming votes to see if they are valid. Like in the example above, hackers have overidden the Flash defense and submitted votes straight into the system which did no extra filtering.

2ng mistake is not to lock access the moment the time expired. Heard many votes cam 2-3 hours later which is outstandingly stupid. I don't think that 2nd hand coders can mess up like this. Maybe 3rd hand but I never met any of them.

How to build a better poll?

Ditch Flash! It won't be as fancy but it will be more secure. Flash is just bells and whistles. Nothing good for good security and what if some don't have it.

Do server side check for the 24 hour interval for every vote. Make a vote pool and place any new one there and after sanity-checks expose them to public. As a desperate measure add Captchas to secure voting.

Focus on server-side security. It's better to show the vote button all the time to a user but to validate the vote as it comes into the server than to hide the vote button and not to validate each vote hoping the user won't find your hidden button!

Last but not least!

This was good publicity for everyone. There's no such thing as bad publicity … just publicity!

Post Feedback

Rendered On : [Thursday, 07 August, 2008 - 23:12:47 GMT] No Ajax / Flash Used Here

" Science-Blogs@2007 Weblog Awards - Failures and Countermeasures : 5ubliminal's TellinYa "