Transcript Powerpoint format

Web Site Security
Andrew Cormack
JANET-CERT
[email protected]
©The JNT Association, 1999
Where’s the problem?
Number of CIAC bulletins since October 1997:
Apache
0
IIS
5
Solaris
8
Windows NT
8
( Internet Explorer
3 )
See especially CIAC bulletin J-042 on web security
Web Site Security, Andrew Cormack
©The JNT Association, 1999
First fix your host
Minimal configuration

don’t run things you don’t need
Up to date with patches
Keep it that way

new bugs every month
Pay attention to logs

you may only get one warning
Web Site Security, Andrew Cormack
©The JNT Association, 1999
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

Web Site Security, Andrew Cormack
©The JNT Association, 1999
What can go wrong
Denial of service (availability)
Information leakage (privacy)
Loss of control (integrity)
unauthorised modification
 or worse

Web Site Security, Andrew Cormack
©The JNT Association, 1999
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

Web Site Security, Andrew Cormack
©The JNT Association, 1999
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
Web Site Security, Andrew Cormack
©The JNT Association, 1999
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

Web Site Security, Andrew Cormack
©The JNT Association, 1999
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

Web Site Security, Andrew Cormack
©The JNT Association, 1999
Loss of control (fatal)
Allowing readers to run commands
Never 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
Web Site Security, Andrew Cormack
©The JNT Association, 1999
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!
Web Site Security, Andrew Cormack
©The JNT Association, 1999
Conclusion
Don't build on sand
Think carefully about "ease of use”
Plan for the worst
Talk with CERT
Never stop!
Web Site Security, Andrew Cormack
©The JNT Association, 1999
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!
Web Site Security, Andrew Cormack
©The JNT Association, 1999
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 draconian
User education (like viruses) is the best bet
Web Site Security, Andrew Cormack
©The JNT Association, 1999
Web Site Security, Andrew Cormack
©The JNT Association, 1999