Security Part I

1
Security (Part I)

• Web Risks Snooping, Overriding client-side
  checks, and bypassing naïve login screens

2
Whats in store this week

• Introduction to Security
• Importance of Security
• Sample risks

3
Introduction to Security

• When designing for the WWW, we need to pay
  particular attention to the security of our
  applications.
• A badly-written application could corrupt data,
  delete files, allow sensitive and private
  material to become public or even worse...
• ...could allow a cracker an easy route to
  compromise the Web Server it sits in.
• This could allow a cracker to use your system to
  attack others.

4
Introduction to Security

• The aim of this weeks lecture is to give you an
  overview of what kinds of security problems exist
  with Web applications.
• Next week the topic of how to deal with these
  problems will be discussed.

5
Security

• So why should security matter?
• A web server is a gateway into your local
  network, and the whole of the Internet is sitting
  on the other side.
• Some members of the Internet may want to look at
  sensitive information on your network (e.g.
  Password lists, credit card numbers, confidential
  information)
• Others may wish to tamper (change your web page,
  delete your database, format your hard drive)

6
Security

• But why would anyone attempt to disrupt or break
  into a machine?
• Motives
• Casual snooping - Inquisitive crackers who look
  around seeing what they can find, without any of
  the following motives
• Disruption - preventing or inhibiting legitimate
  users from use of the system

7
Security

• More motives
• Espionage - attempting to extract information
  from a system (perhaps commercial information)
• Use of resources - once compromised, a system or
  network can be used to launch attacks on other
  networks
• There are other motives

8
Security

• As you know from the programming modules, unless
  you are very careful in designing and writing
  software, it has bugs.
• Large programs tend to have more bugs.
• In Internet Security circles it is said buggy
  software opens up security holes.
• Therefore unless you are extremely vigilant,
  large programs may present security holes

9
Security

• We will talk next week on some ways to check your
  scripts arent opening holes...
• According to the WWW Security FAQ, there are
  three potentially overlapping sets of risks
• 1. Bugs or misconfiguration problems in the Web
  server that allow unauthorised remote users to
• Steal confidential documents not intended for
  their eyes.
• Execute commands on the server host machine,
  allowing them to modify the system.

10
Security

• 1. (cont)
• Gain information about the Web server's host
  machine that will allow them to break into the
  system.
• Launch denial-of-service attacks, rendering the
  machine temporarily unusable.
• 2. Browser-side risks, including
• Active content that crashes the browser, damages
  the user's system, breaches the user's privacy,
  or merely creates an annoyance.
• The misuse of personal information knowingly or
  unknowingly provided by the end-user.

11
Security

• 3. Interception of network data sent from browser
  to server or vice versa via network
  eavesdropping. Eavesdroppers can operate from any
  point on the pathway between browser and server
  including
• The network on the browser's side of the
  connection.
• The network on the server's side of the
  connection (including intranets).
• The end-user's Internet service provider (ISP).
• The server's ISP.
• Either ISPs' regional access provider.

12
Security

• Whilst all three are valid risks, as Web
  Application authors, we are typically most
  interested with (1) and (3).
• Web Server risks
• Network interception risks

13
Security - Web Server

• Typical Web Server risks
• 1) Mailing the password file to the attacker
  (unless shadowed)
• 2) Mailing a map of the file system to the
  attacker
• 3) Mailing system information from /etc to the
  attacker
• 4) Starting a login server on a high port and
  telneting in
• 5) Many denial of service attacks massive file
  system finds, for example, or other resource
  consuming commands
• 6) Erasing and/or altering the server's log files

14
Security - Interception

• Network Interception Risks
• snooping or listening
• Information is very often sent over a network as
  plain text
• Anyone listening to the traffic can hear all this
  noise by setting their NIC into promiscuous
  mode - i.e. accepting all packets, even those not
  meant for them
• This is called packet sniffing

15
Security - Interception

• Typically, Web servers send everything in plain
  text
• But well discuss Encryption and S-HTTP next week
• Pages and data often travel across multiple
  networks, all in plain text for anyone sniffing
  any of those networks to read in full
• Are you sending passwords over the Internet?
  Credit Card numbers?
• It doesnt make any difference if it is a
  password field on your form!

16
Security - Interception

• Sniffing

Server A sends a message to Server B
Q. What if the message held Credit Card numbers
or passwords?
17
Security - Interception

• Spoofing/Man-in-the-middle attacks
• IP spoofing (pretending to have the IP address of
  another machine) and then e.g.
• waiting for legitimate users or other machines to
  try and message or use the system (maybe entering
  passwords etc?) - this is IP Spoofing
• Intercepting messages passed from server to
  server, and altering the message in the process -
  this is a man-in-the-middle attack
• Intercepting or saving old messages, then
  transmitting them later - retransmission

18
Security - Interception

• Man-in-the-middle attacks

Server A believes Server C is actually Server B
Server B believes Server C is actually Server A
Server C
Server C can then act as a go-between in the
conversation between A and B, and have access to
all data being transmitted, as well as
potentially change instructions/messages
19
Security - Interception

• Replay attacks

Server A sends a message to Server B
Later, Server C replays the message to Server B
Q. What if the message was a bank account
transfer?
20
Security

• Invalid input attacks
• Feeding invalid or unexpected values to CGI
  scripts.
• Overriding JavaScript validation.
• Overwriting hidden fields.
• E.g. Perhaps your form has a hidden field for the
  price (say, 500), and perhaps you have
  JavaScript validation to ensure that you can only
  order between 1 and 10 of the item?

21
Security

• A script can be invoked from any form, anywhere.
  Or, you can bypass the form entirely and the
  script invoked by directly requesting its URL
• /order.cgi?price1quantity10000
• Oops! 10,000 units super cheap!
• Or worse still if you are automatically charging
  credit cards...
• /order.cgi?price500quantity-100
• A substantial refund!
• And it could get worse.

22
Security

• There is a class of attack known as SQL
  Injection.
• By creating a specially formed input string, it
  may be possible to alter the SQL commands being
  used in your application.
• select from Student where loginid and
  passwordpassword
• What if id "10999999 --"?
• What about "10999999 drop table Login --"
• (Can PHPs addslashes help to avoid this)

23
Security

• Additionally, invalid input can lead to cross
  site scripting (XSS).
• To begin, imagine you have a web page that prints
  out the value of a variable.
• print "ltpgtvalue is valuelt/pgt"
• What if value "ltimg src'http//www.goatse
  .cx/hello.jpg'gt"¹ ?
• 1. If you have never heard about the now-closed
  shock site Goatse, you are very fortunate.
  However, you can read about it at
  http//en.wikipedia.org/wiki/Goatse.cx

24
Security

• If that isnt bad enough, XSS can be used for
  cookie theft as described at
  http//www.cgisecurity.com /articles/xss-faq.sh
  tml
• A classic example is using Javascript on the page
  itself to access a cookie set by the web site we
  are viewing, and then sending it to an external
  (untrusted) site.
• You could try altering the webpage through the
  DOM.

25
Security

• Back Door
• This is something which allows entry to a system,
  completely disregarding any security on the
  front door.
• Often installed after a system has been
  compromised in some other fashion, but sometimes
  around due to poor design in the program
  (originally meant for debugging etc, and left in
  accidentally?).
• Dont put these into your scripts!
• (What about the computer WORR in the film
  Wargames)

26
Security

• Reading browser histories
• If you have a login page, but all it does is act
  as a gateway to other unsecured pages, there is
  nothing to stop someone peering over the shoulder
  of an active user, or browsing the history file
  of the computer to get the addresses of pages not
  usually accessible without going through the log
  in page.
• Another instance of security-by-obscurity.
• Ensure your pages beyond the login are protected
  somehow too if needed.

27
Security
28
Security - Secure Server

• Some definitions of security rely more on feel
  good factor than actual security
• It is missing the point to try and implement very
  strong security in certain areas whilst leaving
  other, more important, areas unprotected
• Question What does a secure server mean as
  pertains to e-Commerce sites?

29
Security - Secure Server

• Does it mean sending pages over an encrypted
  channel (such as HTTPS as discussed next week)?
• Would the server still be secure if you store
  passwords in plain text in the database?
• http//news.bbc.co.uk/1/hi/wales/690574.stm -
  Teenagers bailed on hacking charges

30
Security - Secure Server

• Or if the response page contains the value of
  your password as a hidden field?
• Or if I can obtain someones password using
  social engineering?
• http//news.bbc.co.uk/1/hi/england/ gloucestershir
  e/3152937.stm - Woman's PIN blunder led to theft

31
Security - Secure Server

• A Web server that supports any of the major
  security protocols, like SSL, that encrypt and
  decrypt messages to protect them against third
  party tampering. Making purchases from a secure
  Web server ensures that a user's payment or
  personal information can be translated into a
  secret code that's difficult to crack. Major
  security protocols include SSL, SHTTP, PCT, and
  IPSec (Webopedia)

32
Security

• General precepts of Security
• Trust no-one - especially not remote hosts.
• The browser can lie!
• Begin with allowing nothing, and then list what
  to allow
• DO NOT begin with allowing everything, then
  listing what to disallow - you might forget
  something vital!
• Security should be simple - complex systems are
  harder to prove secure.
• Security is not an add-on or an extra It
  should be considered from the very beginning
  upwards.
• Security is only as strong as the weakest point.

33
Security

• No security can make a system 100 foolproof.
• The only way to do that would be to take a
  totally secure machine, with no external
  connections of any kind (network, mouse,
  keyboard) and lock it in a safe
• Not very useful, and even that wouldnt quite be
  100 uncrackable!
• Dynamite

34
Security

• In practice security is a trade-off between total
  security and usability.
• The more flexibility a system has, the more it
  opens itself up to abuse.
• Security should not rely on keeping the inner
  workings secret - this is security by
  obscurity, and as soon as the cat is out of the
  bag it is no better than having no security at
  all.

35
Security

• The WWW Security FAQ chapter on CGI
  http//www.w3.org/Security/Faq/wwwsf4.html
• The CGI Security FAQ http//www.improving.org/pau
  lp /cgi-security/safe-cgi.txt
• Rule 1 Never ever pass unchecked remote user
  input to a shell command.
• exec()
• eval()
• system()
• open()

36
Next Week

• Security (Part II) More on security - and things
  we can do to enforce it.
• Perl Taint mode
• Authentication
• Sessions
• Cookies
• S-HTTP

37
References

• news//comp.risks
• http//www.w3.org/Security/
• http//www.w3.org/Security/Faq/
• http//www.internet-tips.net /Webmaster/CGI_s
  ecurity.htm
• http//wp.netscape.com/security /techbrief/s
  sl.html
• http//hoohoo.ncsa.uiuc.edu /cgi/security.h
  tml
• http//www.oreilly.com/catalog /cgi2/chapter/c
  h08.html

38
References

• http//www.perldoc.com/perl5.8.0 /pod/perlse
  c.html
• http//www.webopedia.com/TERM/S/SSL.html
• http//news.bbc.co.uk