Web Site Security

Andrew CormackJANET-CERT

Andrew.Cormack@ukerna.ac.uk

©The JNT Association, 1999

©The JNT Association, 1999Web Site Security, Andrew Cormack

Where’s the problem?

Number of CIAC bulletins since October 1997:Apache 0IIS 5Solaris 8Windows NT 8

( Internet Explorer 3 )See especially CIAC bulletin J-042 on web security

©The JNT Association, 1999Web Site Security, Andrew Cormack

First fix your host

Minimal configuration don’t run things you don’t need

Up to date with patchesKeep it that way

new bugs every month

Pay attention to logs you may only get one warning

©The JNT Association, 1999Web Site Security, Andrew Cormack

Limit the scope for errors

Minimal access restricted users restricted hosts (e.g. use TCP wrappers)

Single function others will compete with web serving and make operation much more complicated

©The JNT Association, 1999Web Site Security, Andrew Cormack

What can go wrong

Denial of service (availability)Information leakage (privacy)Loss of control (integrity)

unauthorised modification or worse

©The JNT Association, 1999Web Site Security, Andrew Cormack

Denial of service

Not much you can do to prevent it! when does popularity become DoS?

Precautions have more performance than likely attacker have different servers for different readers be ready with a "sorry" backup

©The JNT Association, 1999Web Site Security, Andrew Cormack

Information leakage (web stuff)

Web is designed for publishing

Protection mechanisms are weak files have many names addresses can be faked passwords can be sniffed

Shared authentication puts other systems at risk!Use offline encryption if you must

©The JNT Association, 1999Web Site Security, Andrew Cormack

Information leakage (system stuff)

Caused by badly configured servers badly written scripts misguided scripts (finger, last, etc.)

Can lose script source code password or other configuration files

©The JNT Association, 1999Web Site Security, Andrew Cormack

Loss of control (severe)

Beware of uploads replacing graphics or your home page who can publish? how do you know who they are?

Unexpected interactions uploads of scripts java applets on multi-purpose server

©The JNT Association, 1999Web Site Security, Andrew Cormack

Loss of control (fatal)

Allowing readers to run commandsNever run server as root

hackers have to work harder

Never put test scripts on live server and check, check and re-check production scripts

Compromised system probably a write-off

©The JNT Association, 1999Web Site Security, Andrew Cormack

The worst cgi script

w $1

What if $1 is ”andrew;cat /etc/passwd”...Use perl -wT to trap errors

better a 500 error than a lost system

Even commercial scripts have errors!

©The JNT Association, 1999Web Site Security, Andrew Cormack

Conclusion

Don't build on sandThink carefully about "ease of use”Plan for the worstTalk with CERTNever stop!

©The JNT Association, 1999Web Site Security, Andrew Cormack

Don’t forget the browser

Browsers sometimes run untrusted code ActiveX - can run any Windows application JavaScript - limited but powerful functions Java - runs in a sandbox, but this may leak Added “viewers”, e.g. word, excel

Beware!

©The JNT Association, 1999Web Site Security, Andrew Cormack

Applet capabilities

Such programs can do anything the user can read or write files on local disk or network make calls on the network

Browser control is a hard problem but not unique: mail and office apps are the same

Technical fixes are draconianUser education (like viruses) is the best bet

©The JNT Association, 1999Web Site Security, Andrew Cormack