Advanced Commercial Web Site Design: ServerSide Scripting

1
Advanced Commercial Web Site Design Server-Side
Scripting

• Session 12 Security Web 2.0

2
Outline

• Authorization, Authentication Control Access
• Security issues
• Possible attacks
• Database considerations and SQL injection
• Course Review

3
Authorization, Authentication Control Access

• Often, you need to protect resources to ensure
  that only authorized users have access.
  Authorization provides controlled access to
  protected resources. However, authorization is
  based on authentication and access control.
  Authentication is a process that verifies the
  identity of a user, device, or other entity in a
  computer system, usually as a prerequisite to
  allowing access to resources in a system. Access
  control is a process that determines whether this
  authenticated user is entitled to access a
  particular requested resource.

4
Authorization, Authentication Control Access
(cont.)

• Authorization is not required to access
  unprotected resources. Because authorization is
  built upon authentication, authentication is also
  not needed to access unprotected resources.
  Accessing a resource without authentication is
  referred to as unauthenticated or anonymous
  access.

5
Authorizing a user

• In order to only authorize a subgroup of visitors
  to a web application, careful design should take
  place in both
• Obtaining the details (username, password) of the
  user.
• Authenticating these details against a reliable
  and uncompromised source.

6
Obtaining user details (securely)

• The details of the user should be part of a Form
  that is submitted to the authorizing agent on the
  server. It is important to follow these steps
• POST method should be used for submitting the
  fields of the form(otherwise the field values
  will be visible in the URL)
• ltform action"authenticate.phpgt" method"POST"gt
• The text field of the password should be
  masked(show asterisks or other special
  characters when the user enters its password)
• ltinput type"password" name"password"gt

7
Checking the details

• Once the Form is submitted, the authorizing agent
  should check the correctness of this information
  against an internal file or database.
• The use of a file containing the usernames and
  passwords is discouraged since it can be easily
  compromised.
• A table in the database should be used,
  containing the following fields (i.e. app_Users)
• ID
• username
• password
• Other fields, such as accessDate, sessionId, etc.

8
Example on authorization

• Login page (login.php)
• ltform action"authorize.phpgt" method"POST"gt
• Username
• ltinput type"text" name"username"gt
• ltbrgt
• Password
• ltinput type"password" name"password"gt
• ltinput type"submit" value"Login"gt
• lt/formgt

9
Example on authorization (cont.)

• Authorization page (authorize.php)
• // connect to database server
• mysql_connect('localhost', user_3xx",
  ")
• // select a database
• mysql_select_db (db3xx")
• query "SELECT username, password FROM
  app_Users WHERE username'".username."' AND
  password'".password."'"
• // execute the query
• result mysql_query( query )
• if (mysql_num_rows(result) 1)
• // User authenticated
• //// Redirect to the next web page of the
  application
• echo "Authenticated!"

10
Exercise 12.1

• Extend the previous example on authorization, to
  perform the following tasks
• The authorizing script should redirect back to
  the login page if the details were not correct
  (not match the ones in the database)
• The authorizing script should redirect to a
  welcome screen if the user is authorized

11
Exercise 12.1 (cont.)

• In the case of rejected authentication (1), the
  login script should show appropriate messages in
  red colour
• Error message Incorrect username or password!
  Please try again
• If the user exists in the database but provided
  the wrong password.
• Error message Access to the web-application is
  restricted to registered users. Please login
  first
• If the user does not exist in the database at all.

12
Possible attacks

• Once a web site is up and running, it is exposed
  to everybody. Visitors that are interested to its
  content but also bad guys who want to take
  advantage of it.
• For personal web pages, the risk is not high.
• For e-Commerce applications the risk is very
  high, since sensitive details about the customers
  are maintained. Compromising such a source of
  information, one can get hold of passwords, bank
  details, transactions, etc.

13
Code execution in text format

• Consider a small script that is writing into a
  file a string that is passed from a request, for
  example comment.
• Another script is reading that file and shows all
  the comments stored there.
• What will happen if one of the comments was
• ltSCRIPT LANGUAGEJavaScriptgtwindow.locationht
  tp//www.crackersite.com/lt/SCRIPTgt
• Instead of showing the page with the comments, it
  would redirect to the web site of the cracker!
• Solution
• Use function htmlspecialchars(string) to
  sanitize the input data.

14
Reading (other) files

• Consider a script that navigates to the following
  web-pages through a ltselectgt tag. The resulting
  page is static and is read directly from the
  disk.

• lt?php
• fp fopen(car)
• print( fread( fp, filesize( car ) ) )
• fclose()
• ?gt
• ltformgtltselect namecargt http//.......?carused
  cars.html
• ltoption valueusedcars.htmlgtUsed
• ltoption valuenewcars.htmlgtNew
• ltinput typesubmit valueShow me moregt
• lt/selectgtlt/formgt

15
Reading (other) files (cont.)

• What will happen if a cracker use /etc/passwd
  instead?
• The script will present him the passwords of all
  the users.

Solution lt?php if (IsSet(car)) switch
(car) case usedcars.html fp
fopen(car) print( fread( fp, filesize( car
) ) ) fclose() break ?gt
16
Even more security

• Passwords are sensitive pieces of information and
  ideally should be encrypted in order to achieve
  greater security.
• There are two ways to deal with encrypted
  passwords
• 1. Keep the password encrypted in the database.
  When a user provides a password, the one stored
  is first decrypted and then checked against the
  provided one.
• Problem If a password can be decrypted, is not
  secure enough!

17
Even more security (cont.)

• 2. Keep the password encrypted in the database,
  using one-way encryption. When a user provides a
  password it is first encrypted and then is
  checked against the stored one.
• Solution
• Use function crypt( string ) to encrypt the
  password

18
Database security

• Privileges and GRANT statements
• CREATE USER 'dbelis'_at_'' IDENTIFIED BY ''
• GRANT USAGE ON . TO 'dbelis'_at_'' IDENTIFIED
  BY '' WITH MAX_QUERIES_PER_HOUR 0
  MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0
  MAX_USER_CONNECTIONS 0
• CREATE DATABASE IF NOT EXISTS dbelis
• GRANT ALL PRIVILEGES ON dbelis . TO
  'dbelis'_at_''
• gtgtgt SET PASSWORD FOR 'dbelis'_at_'' OLD_PASSWORD(
  'letmein' )

19
Database security (cont.)

• Local vs Remote user
• GRANT ALL PRIVILEGES ON dbelis . TO
  'dbelis'_at_''
• gtgtgt SET PASSWORD FOR 'dbelis'_at_'' OLD_PASSWORD(
  ' )

20
Database security SQL injection

• SQL injection
• It is a trick to inject SQL query/command as an
  input possibly via web pages. Many web pages take
  parameters from web user, and make SQL query to
  the database. Take for instance when a user
  login, web page that user name and password and
  make SQL query to the database to check if a user
  has valid name and password. With SQL Injection,
  it is possible for us to send crafted user name
  and/or password field that will change the SQL
  query and thus grant us something else.1

1. http//www.securiteam.com/securityreviews/5DP0N
1P76E.html
21
Final Course Review

• Topics covered
• The future