10

Stupidity versus Malice

Posted by iphp on Sep 30, 2009 in Security

As a web developer, I am required to build web applications and secure websites. One of the key requirement is to create a secure and well protected system to keep attackers at bay. Although securing the website from malice is important, it is also important to secure the web application from stupidity. Stupidity from the privileged users, administrators, developers, etc. The cost of stupidity is often underestimated. By stupidity I mean lack of average intelligence assumed for a particular task or not thinking through atleast a few worst case scenarios prior to doing something.

Let me give you a few big examples from history and recent times.

1) Data worth 2 billion dollars lost in courier
In 2007, 25 million child benefit records was sent from one government department to another and was lost by the courier company. The discs were sent by a junior staff member unencrypted and unregistered. The discs contained all kinds of personal data, names and ages of children, bank savings account numbers, partners details and even National Insurance Numbers (Equivalent to the Social Security Numbers).  The costs that this caused UK is not clear but it did involve high profile resignations, weeks and weeks of political debates, banks monitoring millions of accounts for fraudulent activity, etc. Some estimate the data alone could be worth over $2 billion in criminal hands.

2) The Honda Point Disaster (Off California Coast)

Aerial view showing all seven destroyers

Aerial view showing all seven destroyers

This was the largest peacetime loss of U.S. Navy ships in which seven destroyers were lost. This tragedy was not caused by malice. Twenty-three sailors died in the mishap. Two other destroyers were slightly damaged. The navy court ruled it as a fault of the navigators and the captains of each ship. How did this happen? The flagship was equipped with a radio navigational receiver, but ignored the bearings, believing them to be erroneous. No effort was made to take soundings or depth measurements. These operations were not performed due to the need to slow the ships to take readings. The ships were performing an exercise that simulated wartime conditions, hence the decision not to slow down. In this case, the dead reckoning (method of estimating position) was wrong and the mistake fatal. The need to slow the ship might also reminds us of another disaster, the Titanic!

3) Aviation Accidents
Boeing studied commercial jet accidents (not including hijacking, test flights, etc) between 1959 to 2008. They determined the primary cause of Airline hull loss accidents (aircraft beyond repair) to be the following:

  • 55%: Flight crew error
  • 17%: Airplane
  • 13%: Weather
  • 7%: Misc./Other
  • 5%: Air traffic control
  • 3%: Maintenance
  • Clearly a lot of these are preventable and a lot of lives could have been saved. Flight crew error and the Air traffic control accounts to about 60% of all hull loss accidents.

    In Conclusion
    Accidents do and will happen, I would recommend developers to think about stupidity and not just malice when building systems. I have two interesting quotes to leave you with.
    Albert Einstein - Two things are infinite: the universe and human stupidity; and I’m not sure about the universe.
    Hanlon’s Razor Never attribute to malice that which can be adequately explained by stupidity.

    Do share incidents that you have come across during your career.

    Tags: ,

     
    17

    How to detect if your webserver is hacked and get alerted

    Posted by php-manual on Jan 19, 2009 in PHP, Security, Web

    We all do our best to write excellent code and also keep our installations of popular open source tools like Wordpress, Joomla, Oscommerce, Drupal, phpmyadmin and all its plugins always updated to prevent any attack or hackers using known exploits on them. This article is not aimed at going through all those methods to help you secure your website BUT focuses on how to send you an alert once your website is hacked and running “hidden” code that you didnt write.

    Read more…

    Tags: , , , ,

     
    2

    PHP session fixation attacks

    Posted by php-manual on Jan 14, 2009 in PHP

    Session fixation attacks attempt to exploit the vulnerability of a system which allows one person to fixate (set) another person’s session identifier (SID). Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs (query string) or POST data.

    Example of such an attack: Lets take an example of a banking website which provides login to access banking features. (this can be any site which allows users to login).
    EG: http://www.poorbanking.com

    1) Hacker
    Creates a very a link and sends visitors to the site as http://www.poorbanking.com/index.php?PHPSESSID=1234
    Lets assume PHPSESSID is the name of the cookie / variable used to store session information. It is very easy for anyone to find this by just visiting the site once.

    2) Hacker sends link to the target user.
    http://www.poorbanking.com/index.php?PHPSESSID=1234 by email or placed in a blog etc.

    3) Victim
    Sees the link and clicks on it. The site looks genuine and the victim logs in to the site. At this stage the PHPSESSID is set to PHPSESSID=1234 and user is logged in.

    4) The happy hacker
    Hacker can keep checking if they can login by simply going to http://www.poorbanking.com/showmeaccount.php?PHPSESSID=1234
    where showmeaccount.php is the page after login. They can see that once the user has logged in they can easily get access to the page.

    Work around to this problem

    Just prior to setting such a session variable, a call to session_regenerate_id() can help to protect against a session fixation attack.

    See more information at http://en.wikipedia.org/wiki/Session_fixation

    Tags: , ,

    Copyright © 2010 PHP, Web and IT stuff All rights reserved. PHP Web development in London.