Posts Tagged ‘Security’

My car as an analogy for web security

Saturday, May 17th, 2008

screwdriver as car theft deviceI live in a bad neighbourhood…well, okay, not a really bad neighbourhood but its close proximity to the CBD and its abundance of funky bars, galleries and restaurants is neatly balanced by a high concentration of government housing that seems to go hand-in-hand with junkies panhandling outside the supermarket, groups of people drinking in the street during the day, and the occasional stabbing near the public housing estate.

Anyway, living in my neighbourhood means that people keep trying to break into my car. I usually know if they have been successful when I find my car unlocked in the morning with the ashtray open and the contents of the glovebox tossed onto the passenger-side floor. Obviously they are looking for small change to feed a drug habit, rather than trying to steal the whole car.

I wasn’t terribly concerned by this until a particularly incompetent thief broke both my car doorlocks when they tried to open the door with a screwdriver. I had to climb into the car through the boot.

So I decided that I would make my car immune to that kind of attack. I installed a central locking kit and disconnected the key lock from the rods inside the door. For good measure I filled the keyholes with epoxy, so there wasn’t any tempting hole for screwdriver-wielding miscreants.

About a week later, I found that someone had jammed a screwdriver in the lock anyway. They hadn’t been able to get in, because the lock wasn’t connected to anything, but they had managed to bend the door paneling around the lock.

After some amateur panel beating, it was time for a rethink. I made little signs saying “no money in car” and stuck them on the window above each lock. I superglued a 1 cent coin over the top of the keyhole and covered the keyhole with electrical tape that matched the car body colour, and finally, I left the glovebox and ashtray open to show that there was nothing worth stealing inside the car.

Another week later, I found that someone had ignored my signs, peeled the tape off the lock on the driver’s side, pried the 1 cent coin off the lock, found that their screwdriver trick didn’t work in the driver’s side door, walked around to the passenger side and peeled off the tape on that side before giving up.

So what lessons can we transfer to web security?

  1. The thieves weren’t targeting my car in particular, they were just trying the same exploit (screwdriver in door lock) on every car in the street. The majority of website hacking attempts are due to someone trying a single known exploit on many websites, rather than targeting a single website with many potential exploits. This is because…
  2. …the cost of attack is low. An attack on many websites that focuses on a single exploit is cheap because it can be automated, and once something is automated, it can be re-used for close to zero cost. Trying car door handles as you walk down the street is a low-cost attack as it is quick and has low probability of being caught (contrasts with breaking a car window which would have a higher attack cost as it will attract attention). As the attack cost is so low, a sign which says “no money in car” may not be much of a deterrent, just as I find IIS-only exploit attempts in the logs of my Apache web server.
  3. The damage caused by an unsuccessful exploit attempt is usually zero for a web site. Seeing IIS-only exploits in my Apache log doesn’t worry me. Once I modified my car so that its locks could no longer be broken by a screwdriver (expensive and time-consuming to fix), then attempts to break into my car stopped worrying me.
[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Seven Web Application Security Myths

Sunday, May 4th, 2008
  1. HTTPS will protect your application. Just because a user’s browser displays a lock icon when they visit your website, doesn’t mean that your website is secure. HTTP over SSL (HTTPS) only encrypts the traffic between the user and the web server, which prevents snooping of the user’s traffic. It does not prevent a user sending malicious requests to the web server.
  2. A firewall will protect your application. Firewalls are great; you can lock down every non-essential port on your server. But you can’t prevent people from accessing port 80 (or 443) or you will have the worlds least-used web server. If port 80 is open, malicious requests can be sent to your web application.
  3. A locked down server build will protect your application. You can disable all non-essential services on your server, and you can run your web server or application server under a restricted account that cannot read or write to any files outside the web folder, but . vulnerabilities introduced by developers, rather than
  4. A web Intrusion Detection System will protect your application. nuh uh
  5. No one will target your application. (do you appear on a search engine?)
  6. Using off-the-shelf software will protect you. patch levels. when they go down, they go down big. Not a big fan of reinventing the wheel. common components.
  7. Writing custom software will protect you. no secure languages. secure components. heuristic attack. - I see a field

 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Akamai - State of the Internet

Friday, April 4th, 2008

Akamai, who provide transparent mirroring of web content for high-traffic websites, see a large sample of Internet traffic. They have started to report on some of the trends they see in their traffic patterns (while some not so subtle points about how good they are). Their first report covers Q1 2008 (January - March). The report is available from http://www.akamai.com/stateoftheinternet/ (registration required). Here are some of the security-related things that I found interesting

  • Approximately 2% of all inter-domain Internet traffic was DDoS traffic (does not include spam, phishing, scans or other malicious traffic).
  • The “Anonymous” DDoS attack on the Church of Scientology website generated 220 Mbps of attack traffic at peak. This was a comparatively small attack, but received attention in the mainstream media.
  • In January, an automated SQL injection attack compromised 70 000 sites including .edu, .gov, and several websites belonging to Fortune 500 companies. 11, 12
  • Drive-by install (2 examples).

 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]