Security Part II

1
Security (Part II)

• Solutions HTTPS, Sessions, authentication

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
• 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
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.
• And then to conclude, a little about how to store
  information between different web pages on your
  site...

6
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.
• There are a few things we can do to minimise
  these risks.

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

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

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

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

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

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

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

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

15
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!

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

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

18
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

19
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!

20
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

21
Storing Passwords
Password shadow1
MD5 Algorithm
Password Hash 098939FEED3BA17F87863B86E532E208
22
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

23
Storing Passwords
Entered Password shadow1
Password in database shadow1
Entered Password shadow1
MD5 Algorithm
Entered PW Hash 098939FEED3BA17F87863B86E532E208
DB PW Hash 098939FEED3BA17F87863B86E532E208
24
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.

25
Security in PHP

• PHP has a fantastically detailed section in the
  manual about security, which discusses many, many
  issues (both those we have mentioned, and a few
  we have not, for time reasons). This should be
  considered required reading.
• http//www.php.net/manual/en/security.php
• Read through this, as we will discuss this
  briefly in the Thursday workshop.

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

27
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

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

29
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

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

31
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

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

33
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,

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

35
Sessions in PHP

• Added in PHP 4.0
• A way to preserve data across pages.
• Uses cookies and server-side storage of data.
• To use a session call the function
  session_start()
• Note This must be done before you print anything
  to the browser!
• Then, any values that you store in the
  associative array _SESSION can be retained
  within the browsing session.

36
Sessions in PHP

• To ensure these are saved at the end of a page
  execution, call session_commit()
• To close a session and destroy all the stored
  data, use the function session_destroy()
• More details about sessions at http//www.php.net/
  manual/en/ref.session.php

37
Sessions in PHP

• session_start()
• if (!isset(_SESSION'count'))
• _SESSION'count' 0
• else
• _SESSION'count'
• session_commit()

38
Cookies in PHP

• We manipulate cookies in PHP through either
  sessions, or embedding Javascript on the client
  side (not recommended). Alt3ernatively, we can
  set a cooke manually using setcookie().
• session_get_cookie_params() and
  session_set_cookie_params() allow us to access
  the cookies (so remember what we said earlier
  about the anatomy of a cookie).
• session_get_cookie_params() returns an array with
  the following data stored as Strings
• lifetime, path, domain, secure

39
Cookies in PHP

• session_set_cookie_params() takes up to 4
  optional parameters
• session_set_cookie_params(int lifetime, string
  path, string domain, boolean secure)
• So, to summarise, we store information by
  creating a session and storing values as names
  within a special associative array. We access
  manipulate the lifetime, etc. of a cookie by
  special functions.

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

41
Security risks with Cookies

• Additionally, session usage can allow for user
  hijacking or other issues
• A leaked session id gives access to all resources
  associated with the id.
• Unless cookie-based sessions are enabled, the
  URLs will carry session ids.
• Then if you link to an external site, the URL
  including the session id might be stored in the
  external site's referrer logs.
• http//www.acros.si/papers/session_fixation.pdf

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

43
After Christmas

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

44
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