CT30675E Application Development for the Web

1
CT30675E Application Developmentfor the Web

• Week 11Security (Part II)

2
Whats in store this week

• (Brief) Review of Week 10
• Sessions Security
• Cookies
• Anatomy of a Cookie
• Using Perl to manipulate Cookies
• Practical Security
• Perl Taint Mode
• Authentication
• .htaccess, .htpassword
• SHTTP

3
(Brief) Review of Week 10

• Introduction to Security
• Importance
• Motives
• Snooping
• Disruption
• Espionage
• Stealing resources
• Some sample risks
• Server-side
• Browser-side

4
(Brief) Review of Week 10

• Risks (Cont)
• Interception
• Sniffing
• Spoofing/MitM
• Replaying
• Invalid Input
• Back Door
• Browser Histories
• Principles
• Trust No-one
• Trade-offs
• Make it Simple
• Built in from start

5
Firstly...

• A provisional schedule for presentations has been
  published. Please check it and inform us of any
  problems
• You must attend your presentation to pass!
• Late attendance will not be accepted

6
Sessions Security

• Last week, some major concepts of security were
  discussed.
• This week, it is the intention to provide insight
  into some practical solutions to some of these
  problems.
• But first a little about how to store information
  between different web pages on your site...

7
Cookies

• Web pages are stateless - they cannot store
  information between page changes.
• Except by holding it in a form (as hidden fields
  perhaps), and passing it onto any following pages
  using GET or POST.
• Cookies are a mechanism by which state can be
  stored between web pages.
• Cookies are plain text files, stored on the
  clients computer.

8
Cookies

• Web pages or CGI scripts can store and retrieve
  data by using cookies - within certain
  limitations.
• Creation of a cookie can only occur in the header
  of an HTTP object (such as a web page).
• The details of a cookie header is standardised by
  RFC-2109 HTTP State Management Mechanism

9
Cookies

• What can cookies do?
• Store a small amount (at the very most 4KB) of
  plain text information.
• What cant cookies do?
• Access files on the client machine.
• Execute code (such as a virus).
• Force a browser to accept it, if it doesnt want
  to.

10
Anatomy of a Cookie

• Cookies consist of a number of key, value pairs,
  along with up to 4 other optional items of
  information
• expiration date
• domain
• path
• secure flag

11
Anatomy of a Cookie

• Cookies are optionally given an expiration date,
  which states when the cookie is valid until, in
  the format like
• Wdy, 20-Nov-2002 121427 GMT
• If an expiration date is not given, it is assumed
  that the cookie lasts only as long as the Web
  Browser session.

12
Anatomy of a Cookie

• Cookies may be given a domain which specify which
  Internet Domains are able to access the cookie.
• The domain is tail matching, so setting a domain
  of .tvu.ac.uk would allow holst.tvu.ac.uk to
  access the cookie, and also verdi.tvu.ac.uk,
  www.tvu.ac.uk, glass.tvu.ac.uk or in fact
  anything ending in .tvu.ac.uk
• By default, the domain is set to the same host
  name that generated the cookie - e.g.
  holst.tvu.ac.uk

13
Anatomy of a Cookie

• The domain cannot be set to a top level domain
• So no .com or .uk or .net
• The domain cannot be set to a value which the
  issuing server is not a member of.
• So holst.tvu.ac.uk can only set a domain of
• holst.tvu.ac.uk
• .tvu.ac.uk
• This is so that sites cannot share personal
  information with other, unrelated sites - in
  principle.

14
Anatomy of a Cookie

• Cookies may also be given a path which specify
  which local paths on servers in the permitted
  domains can access the cookie.
• So setting a path of /cgi-bin would allow
  /cgi-bin/login.cgi, /cgi-bin/submit.cgi c., but
  not /geoff/cgi-bin/logout.cgi
• By default, the path is set to /, so any web file
  on the same server as originally created the
  cookie can access it,

15
Anatomy of a Cookie

• If a cookie is marked secure, it will only be
  transmitted if the communications channel with
  the host is a secure one.
• But how can we make a secure channel?
• This will be explained later on...

16
Using Perl to manipulate Cookies

• There are two main Perl modules that deal with
  cookies
• HTTPCookies
• CGI (CGICookie is the section of the module)
• The cookie() method of the CGI module allows
  storage and retrieval of these cookies.
• Remember that storage of a cookie must take place
  during the HTTP header (the content-type
  text/html\n\n bit) which is sent back to the
  client before a web file.

17
Using Perl to manipulate Cookies

• Create a new cookie
• cookie query-gtcookie( -namegt'sessionID'
  , -valuegt'xyzzy', -expiresgt'1h', -p
  athgt'/cgi-bin/database', -domaingt'.capricorn.o
  rg', -securegt1)
• Return the cookie with the header
• print query-gtheader(-cookiegtcookie)

18
Using Perl to manipulate Cookies

• The parameters for cookie() include
• -name
• -value
• -expires
• -path
• -domain
• -secure
• The -name is required, but the other parameters
  are optional.

19
Using Perl to manipulate Cookies

• The -value can be any Perl structure - a scalar,
  an array or even a hash. The CGI module
  translates to and from the plain text cookie
  format to Perl structures.
• If -value is omitted, then this will try to
  retrieve a cookie by name.

riddle query-gtcookie('riddle_name') answers
query-gtcookie('answers')
20
Using Perl to manipulate Cookies

• The optional parameters -expires, -path, -domain
  and -secure can be specified as well.
• Once again This must be done before the cookie
  is sent in the header.
• For more information about how to use cookies,
  consult the Perldoc page for the CGI module.

21
Security risks with Cookies

• Cookies are sent as plain text. So
• Any sensitive information is unprotected from
  intruders on the client side.
• Therefore, information of a personal and/or
  financial nature should only be sent over a
  secure channel.
• A spoofer could alter the headers as they travel
  in either direction.
• Therefore the server should be robust enough to
  prevent a bad Cookie from causing failures.

22
Practical Security

• One of the major risks discussed last week was
  that of invalid input to your scripts.
• A poorly designed program can open up serious
  security holes to this kind of attack.
• Whilst there is no substitute to careful planning
  and debugging of your programs, Perl lends a
  helping hand with taint mode.

23
Perl Taint Mode

• To run a script in taint mode, simply add the -T
  flag to your shebang line
• !/usr/bin/perl -T
• While in this mode, Perl takes special
  precautions called taint checks to prevent both
  obvious and subtle traps.
• These checks are performed at run time.
• If any of the taint checks fail, your script will
  die- Insecure dependency

24
Perl Taint Mode

• Firstly, taint mode checks to make sure that any
  directories in the system path are not writable
  by others.
• More importantly, it flags all foreign data as
  tainted, and will refuse to run any command that
  invokes a sub-shell (such as system() or exec()),
  or in any command that modifies files,
  directories, or processes.
• All form data passed to the CGI script is
  considered tainted by Perl.

25
Perl Taint Mode

• There are two exceptions to this rule
• If you pass a list of arguments to either
  system() or exec(), the elements of that list are
  not checked for taintedness.
• Arguments to print and syswrite are not checked
  for taintedness.

26
Perl Taint Mode

• Any variable set to a value derived from tainted
  data will itself be tainted, even if it is
  impossible for the tainted data to actually alter
  the variable.
• Taintedness is associated with each scalar value
  some elements of an array (or hash) can be
  tainted, whilst others are not.
• So, if a scalar becomes tainted, how can we
  un-taint it?

27
Perl Taint Mode

• Laundering
• (Not just something mobsters do)
• The only way to bypass the taint checks is by
  referencing subpatterns from a regular expression
  match.
• Subpatterns?
• 1 2 3 c.
• Perl presumes that you knew what you were doing
  when you wrote the pattern.

28
Perl Taint Mode

• Insecure ENVPATH
• You get this if you are trying to run a system
  call but havent set the Environment variable
  PATH to a specific value.
• This could be risky, as an attacker could
  potentially alter the systems path, and lead to
  your script accidentally executing a trojaned
  system program.

29
Perl Taint Mode

• Because some shells may use the variables IFS,
  CDPATH, ENV, and BASH_ENV, Perl checks that these
  are either empty or untainted.
• Try this line to wipe out all the values of these
  environment variables during the execution of
  your script
• delete _at_ENVqw(IFS CDPATH ENV BASH_ENV)

30
Perl Taint Mode

• Since the main system call (if any) you are
  likely to use is to sendmail (a program on Unix
  for sending e-mails), you can simply open a pipe
  to sendmail, with the flag -t.
• open(MAIL, "/usr/lib/sendmail -t")
• It is then permissible to print out tainted data
  to that pipe, as it is no longer viewed as
  serious a security risk.

31
Authentication

• Often it is necessary to limit access to certain
  areas of a web site to a limited set of users, or
  to a limited set of machines.
• This can be achieved by a number of methods.
• You could check usernames and passwords against a
  database held on the server using a script and
  generate pages depending on the outcome...

32
.htaccess

• Alternatively, to limit access of files, you can
  use .htaccess files (if your server allows them -
  holst does, but you should be aware that not all
  servers do!).
• An .htaccess file is a text file which can be
  placed inside a directory in your web site.

33
.htaccess

• It contains a list of server directives
  (commands), which can perform the following
• Restrict access to certain files or whole
  directories by client IP or host name.
• Restrict access to certain files or whole
  directories by username.

34
.htaccess

• ltFiles .gt
• order deny,allow
• deny from all
• allow from tvu.ac.uk
• lt/Filesgt
• This will prevent anyone browsing from outside
  TVUs computer network from accessing the page.

35
.htaccess

• If you are trying to limit access in this way,
  remember to protect your scripts in this way as
  well as the web pages.
• But bear in mind that an attacker can still spoof
  their IP address or host name to appear as if
  they came from the TVU domain

36
.htaccess

• Now, to limit access on a user-by-user basis
• AuthName "Section Name"
• AuthType Basic
• AuthUserFile .htpasswd
• ltLimit GETgtrequire valid-user
• lt/Limitgt
• This will allow access control from a file called
  .htpasswd

37
.htpasswd

• To add users to the .htpasswd file, you need to
  use the htpasswd system command, from a terminal
  on the server (use PuTTY to connect to holst and
  go from there).
• The .htpasswd file holds a list of users with
  passwords - but the passwords are encrypted (so
  as to prevent passwords being discovered by an
  intruder).

38
Encryption

• As has been frequently mentioned, web files are
  typically sent as plain text.
• Encryption
• is the storing information in a way such that
  whilst the sender and recipient of the message
  can easily convert it back to text with the use
  of a key, anyone else can only do so with extreme
  difficulty.
• The RC5-64 encryption cipher took a distributed
  effort consisting of thousands of machines 4
  years to decrypt a single message.

39
Encryption

• Only one method of encryption is provably 100
  secure
• One-time pads used during WWII.
• The secret key used to encrypt the data must be
  at least as long as the message itself, and truly
  random.
• Every other method relies on the fact that it is
  very very hard and time-consuming to break!

40
SHTTP

• SHTTP was created in order to give protection
  from the snooping attacks outlined last week.
• SHTTP works by encrypting the data as it travels
  to and from the client and server.
• SHTTP resists clear text attacks, replaying and
  man-in-the-middle attacks.

41
SHTTP

• If a server has been properly set up to support
  Secure HTTP, using it is simple. Instead of
  issuing standard http// requests, issue https//
  requests instead.

42
SHTTP

• holst (as well as verdi, and in fact elgar and
  mercury) has been set up for HTTPS.
• Try it out by logging into and using
  https//verdi.tvu.ac.uk - note that you will
  almost certainly get an initial warning from your
  browser stating that the issuing authority is
  not known

43
SHTTP

• Be careful of how you deal with sensitive data on
  your server.
• For example, if a credit card number is received
  over an encrypted channel by your script, make
  sure not to write it to a world-readable file or
  send it anywhere via e-mail (which is
  unencrypted).
• Also, if someone manages to break into your
  server any data stored in plain text will be
  theirs for the taking!

44
Storing Passwords

• Avoid storing passwords as plain text in your
  database If someone manages to access your
  database, they will have access to all these
  passwords
• How many people use the same password for
  different systems?
• Instead, use a one-way hashing algorithm (such as
  MD5 or SHA-1) to encode the password in the
  database

45
Storing Passwords
Password shadow1
MD5 Algorithm
Password Hash 098939FEED3BA17F87863B86E532E208
46
Storing Passwords

• A one-way hash cannot be reversed There is no
  way to retrieve the original text from the hash.
• So, what we do is instead of comparing the text
  of the password typed in to the text in the
  database
• we calculate the hash of the password typed in,
  and compare the hashes

47
Storing Passwords
Entered Password shadow1
Password in database shadow1
Entered Password shadow1
MD5 Algorithm
Entered PW Hash 098939FEED3BA17F87863B86E532E208
DB PW Hash 098939FEED3BA17F87863B86E532E208
48
Storing Passwords

• You can use the DigestMD5 (or DigestSHA1)
  Perl modules to help with calculating file
  hashes.
• use DigestMD5 qw(md5_hex)
• md5 DigestMD5-gtnew
• md5-gtadd(newpass1)
• newpass md5-gthexdigest
• The variable newpass now holds the MD5 hash of
  the file.

49
Some Final Observations

• Avoid giving out too much information about your
  site and server host.
• Never ever pass unchecked remote user input to a
  shell command.
• There's more to safe CGI scripting than taint
  mode.
• Most security holes are exploited by sending
  data to the script that the author of the script
  did not anticipate. - Paul Phillips, Safe CGI
  Programming

50
After Christmas

• Geoff will be lecturing on Implementing web
  standards and accessibility to a web application

51
References

• http//www.cis.ohio-state.edu /cgi-bin/rfc/rfc
  2109.html
• http//www.cookiecentral.com/faq
• http//www.perldoc.com
• http//www.w3.org/Security/Faq/wwwsf4.html
• http//gunther.web66.com/FAQS /taintmode.html
  
• http//www.improving.org/paulp /cgi-security/s
  afe-cgi.txt
• http//language.perl.com/CPAN/doc/FAQs /cgi/per
  l-cgi-faq.html
• http//faq.clever.net/htaccess.htm
• http//apache-server.com/tutorials /ATusing-hta
  ccess.html