1 / 15

Web Site Security

Web Site Security Andrew Cormack JANET-CERT Andrew.Cormack@ukerna.ac.uk ©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

Angelica
Télécharger la présentation

Web Site Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Site Security Andrew Cormack JANET-CERT Andrew.Cormack@ukerna.ac.uk ©The JNT Association, 1999

  2. 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

  3. 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

  4. 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

  5. What can go wrong • Denial of service (availability) • Information leakage (privacy) • Loss of control (integrity) • unauthorised modification • or worse

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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!

  12. Conclusion • Don't build on sand • Think carefully about "ease of use” • Plan for the worst • Talk with CERT • Never stop!

  13. 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!

  14. 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

More Related