Web Security

1
Web Security
Raval Fichadia John Wiley Sons, Inc. 2007

• Chapter Twelve
• Prepared by Raval, Fichadia

2
Chapter Twelve Objectives

• Learn the basic concepts of web infrastructure
  and associated terminology.
• Understand the risks that impact web
  infrastructure and the controls to mitigate them.
• Gain the skills to assess the security posture of
  a web infrastructure and make management
  recommendations.
• Apply security principles and best practices to a
  web infrastructure.

3
The Big Picture

• Elements of the web infrastructure.
• Some risks that impact the infrastructure.

4
Web primer

• Web Series of computers connected to each other
  via a network (Internet) and use common set of
  languages.
• Broadly speaking, web essentially is a series of
  clients (browsers) and servers (web servers) that
  talk to each other via an agreed upon protocol
  (http), display results in a common format (HTML)
  over a shared network (Internet).
• The web client is essentially an application
  software, commonly known as a browser. Examples
  of browsers include Microsofts Internet
  Explorer, Mozillas Firefox, Apples Safari, etc.

5
Web primer

• Web Series of computers connected to each other
  via a network (Internet) and use common set of
  languages.
• Web clients perform the following key tasks
• Send requests to web servers
• Use http or SSL to send requests
• Receive response and render it on screen
• Run mobile code (ActiveX, Java applets) sent by
  the server
• In addition, web browsers can support other
  protocols like ftp to transfer files. Some of
  the newer browsers support transfer technologies
  like BitTorrent too.

6
Web primer

• Web Series of computers connected to each other
  via a network (Internet) and use common set of
  languages.
• Web servers receive the requests from the web
  browsers and respond via one of the following
  means
• Send a static page back to the browser
• Forward the request to a web application to
  compose a response
• Send mobile code to the browser to execute
• Responses from web servers are typically in HTML
  format. Over the last few years, responses in
  XML format have become popular which are rendered
  by the browser for display. Also, for
  mini-browsers, the responses maybe in WML format.

7
Web primer

• Web Series of computers connected to each other
  via a network (Internet) and use common set of
  languages.
• Common web servers include open-source Apache,
  Microsofts IIS, etc.
• Applications servers often receive the request
  from web servers and host the business logic to
  build a response.
• They host the web applications
• Communicate with the backend databases via
  ODBC/JDBC
• Provide a robust support environment for the
  applications (clustering, redundancy, security,
  etc.)
• Common application servers include IBMs
  WebSphere, BEAs WebLogic, etc.

8
Web primer

• Web Series of computers connected to each other
  via a network (Internet) and use common set of
  languages.
• Web browsers, web servers, application servers,
  and databases are key components of a web
  infrastructure.

9
Management concerns

• Concerns about operating system security
  typically include the following
• Maximizing the availability and performance
  companys web sites to protect revenue and image.
• Maintaining the integrity and confidentiality of
  employee and customer data passing through web
  applications.
• Alleviating privacy concerns for employees and
  customers.
• Keeping up with existing and upcoming security
  threats and implementing mitigating controls.
• Having an effective backup, recovery, business
  resumption and a disaster recovery plan.

10
Risks and controls

• Web browsers Client applications used by end
  users to request and receive responses from
  websites.
• Web browsers are users front-end into web
  applications.
• Web browsers have become another target for
  malicious users to attack others. Some of the
  risks associated with web browsers include
• Privacy concerns for end users
• Attacks on session management
• Risk of mobile code
• Insecure security zones
• Phishing scams

11
Risks and controls

• Privacy Web browsers can lead to privacy
  concerns for end users.
• Web browsers have features that improve browsing
  experience and convenience for web users.
  However, these can cause privacy concerns.
• The autocomplete feature in some browsers like
  Internet Explorer remembers entries made by users
  on web pages, search engines, text boxes.
• History feature within browsers maintains a
  history of websites visited by the user. Some
  even maintain a log of files transferred over the
  web.

12
Risks and controls

• Privacy Web browsers can lead to privacy
  concerns for end users.
• Many browsers remember a feature to remember
  userIDs and passwords for logging onto various
  websites.
• Most browsers maintain a cache that contain local
  copies of web pages visited by users.

13
Risks and controls

• Privacy risks
• Anyone with physical access to the machine can
  gain a fairly detailed view of activities of the
  previous user.
• Controls
• Disable autocomplete, history, cache features
  however, this comes at a loss of functionality.
• Newer browsers come with clean-up private data
  upon exiting option which helps maintain privacy.

14
Risks and controls

• Session management Web browsers have to maintain
  sessions with websites.
• HTTP is stateless protocol every transaction
  between the browser and the server is independent
  of each other. Subsequent transactions dont know
  anything about previous transactions (state is
  not maintained).
• This poses problems for applications that need
  state information to manage a session.
• For example, it may authenticate a user in a
  transaction, and would need to remember the user
  is authenticated for subsequent transactions
  until the user logs out.
• Web developers achieve session management via a
  couple of means cookies and session IDs.

15
Risks and controls

• Session management Cookies help maintain state.
• Cookies are small data files that are given to a
  browser by a web application when a user first
  visits.
• Every subsequent visit, the application checks if
  a cookie exists (and if so, its contents) and
  thus knows if a user has previously accessed the
  application and what was done in the previous
  transaction.
• Cookies can be persistent (written to hard drive)
  or non-persistent (in browser memory).
• Cookies can have expiration dates.

16
Risks and controls

• Session management Cookies help maintain state.
• Cookies can be secure (encrypted in transmission)
  or non-secure (not encrypted).

17
Risks and controls

• Session management Session IDs help maintain
  state.
• Session IDs are token numbers given to a client
  by a web application when a user first visits.
• The session data associated with the user is
  stored on the server side (as opposed to cookies
  which are stored on client) and can be referenced
  via the session ID.
• Every subsequent visit, the client provides the
  session ID to the application which checks the
  session store and thus knows if a user has
  previously accessed the application and what was
  done in the previous transaction.

18
Risks and controls

• Session management Session IDs help maintain
  state.
• Session IDs can be passed via the URLs or via
  hidden fields in the forms submitted.

19
Risks and controls

• Session management risks
• Cookies can manipulated by end users to elevate
  privileges or impersonate others.
• Cookies can be sniffed/stolen leading to
  impersonation.
• Session IDs maybe predictable allowing attackers
  to impersonate other users.
• Session IDs may be sniffed.
• Controls
• Encrypt the contents of the cookies to prevent
  manipulation.

20
Risks and controls

• Controls contd.
• Encrypt the contents of the cookies to prevent
  manipulation.
• Implement checksums on cookies and/or session IDs
  to ensure they havent been tampered with.
• Avoid storing authentication credentials in
  cookies. Server side storage of data is more
  secure.
• Session IDs should be random preventing its
  prediction.
• Use SSL or other encryption methods to prevent
  sniffing.

21
Risks and controls

• Mobile code Code sent by a website to a browser
  for execution.
• The functionality offered to users is greatly
  enhanced by mobile code sent by browsers. Else,
  a browsers would be able to mostly display static
  content only.
• Besides scripting languages like JavaScript, web
  servers send executable code to browsers via two
  key technologies Java applets and ActiveX.
• Java applets are Suns technology whereas ActiveX
  is Microsoft technology. Both work conceptually
  similar, in that upon visiting a website, the
  code is sent to be loaded and executed by the
  browser.

22
Risks and controls

• Mobile code Code sent by a website to a browser
  for execution.
• However, Java applets and ActiveX have
  fundamentally security models.
• Java applets use a sandbox model, wherein the
  code is restricted in terms the system resources
  it can access and system commands it can invoke.
  This prevents the code from doing any damage to
  the system.
• ActiveX follows an Authenticode model, wherein
  the code can perform any action without any
  limitations, however, the code has to be
  digitally signed by the author thereby assigning
  accountability.

23
Risks and controls

• Mobile code risks
• Flaws have been identified that let Java applets
  to breach the sandbox.
• End user is assigned the responsibility of
  determining whether to trust the signed ActiveX
  code.
• Many unsafe ActiveX controls (programs, from
  various vendors) are marked safe-for-scripting
  (which allows them to be invoked by any malicious
  web page/e-mail).
• Controls
• Disable mobile code to the extent possible.

24
Risks and controls

• Controls
• Disable unsigned ActiveX and consider the same
  for signed ActiveX.
• Allow mobile code to be executed only in from
  trusted websites.

25
Risks and controls

• Security zones Browsers allow users to classify
  websites by their trust factor.
• End users can have granular definitions of trust
  via security zones.
• Typical zones include the following (in the order
  of increasing trust / decreasing restrictions)
• Restricted sites
• Internet sites
• Local intranet sites
• Trusted sites
• Every zone can be further customized to specify
  who can run mobile code, who can download mobile
  code, whether to run code with / without
  prompting, etc.

26
Risks and controls

• Security zone risks
• Default zones (Internet) often arent tightly
  secured. For example, it allows ActiveX controls,
  Java, unsigned .NET components etc.
• Controls
• Review each configuration feature available in a
  zone and decide whether it should be allowed or
  not.
• Follow the recommended deny if not allowed
  approach rather than the allow if not denied
  approach.

27
Risks and controls

• Phishing Internet-based scams that targets
  end-users personal/confidential information.
• Scammers ph-ish (fish) for userIDs, passwords,
  bank account numbers, social security numbers,
  etc. from unsuspecting end users via a variety of
  techniques.
• Techniques include sending social engineering via
  spoofed e-mails that seem to come from legitimate
  sites asking for confidential information, fake
  websites that capture userIDs and passwords etc.
• Phishing attacks on an exponential rise some
  reports claim a 8000 percent increase between
  January 2005 and September 2006.

28
Risks and controls

• Phishing risks
• These attack lead to fraudulent transactions,
  identity theft, disclosure of sensitive
  information, etc.
• Controls
• User education is the key to protection against
  phishing attacks.
• Effective spam control can protect users against
  phishing e-mails that lead them to fake websites.
• Newer browsers have features that warn users
  against possible phishing websites.

29
Risks and controls

• Web servers Web servers receive requests from
  browsers and send back responses to the same.
• Web servers are key to a web sites availability
  and need to strongly protected.
• Some of the risks/attacks against web servers
  include
• Insecure operating systems
• Flaws with web server software
• Flaws with add-on components

30
Risks and controls

• Operating system Web server software resides on
  operating systems that have to be secure.
• As mentioned in chapter 7, without a secure
  operating system nothing residing on it can be
  considered secure.
• Web servers often reside in the DMZ instead of
  internal network (to allow outsiders access to
  websites).
• Hence, they are much more exposed to external
  attacks, making the need to secure the OS even
  higher than OS on machines that are within the
  network.

31
Risks and controls

• Operating system risks
• Chapter 7 covered OS risks in detail. In
  general, default accounts, weak file and
  directory permissions, insecure services, missing
  security patches etc. increase the risk of the OS
  (and hence web server) compromise.
• Controls
• Evaluate the need for each service installed on
  the OS. Unnecessary services should be turned
  off.
• Assess the patch deployment process. All
  necessary patches should be implemented.

32
Risks and controls

• Controls contd
• Review authentication methods, user accounts and
  their privileges. Ensure quality user ID and
  password management techniques are used.
• Determine the legitimacy of trust relationships.
• Ensure core OS files are baselined and are
  protected.
• Evaluate the need and security of all file
  shares.
• Determine if additional controls like anti-virus,
  personal firewalls, and intrusion prevention
  systems are in place.
• Review all scheduled jobs and their controls.

33
Risks and controls

• Web server software Web server software receives
  inputs from browsers and responds to them.
• Web server software listens on port 80 for http
  traffic from browsers (port 443 for SSL encrypted
  traffic).
• Web server software often works with databases or
  other application servers to compose responses to
  the browsers.
• The configuration of the software can add several
  risks to web security.
• Web server software often comes with add-on
  components that add programming and/or
  administrative functionality.

34
Risks and controls

• Web server software risks
• Web server software runs as a user on the OS.
  Some installations define this user with high
  privileges (out of choice, ignorance, or
  necessity). This increases the fallout
  associated with a compromise.
• Many default installations come with sample
  scripts and applications preloaded. These are
  often exploited by attackers. For example, IIS
  had a showcode.asp sample code that was often
  used by intruders.
• At times web server software provides detailed
  error messages that helps attackers footprint the
  system.

35
Risks and controls

• Web server software risks
• Web server software may allow for directory
  traversals that allows users to navigate outside
  of directories that store web pages and read
  sensitive files.
• In addition to web server software, the add-on
  components are often susceptible to attacks like
  buffer overflows.
• Controls
• Keep web server software patched.
• Minimize privileges associated with web server
  software.
• Remove all sample scripts, applications etc.

36
Risks and controls

• Controls
• Remove sensitive data from source codes.
• Install web content on a drive that is separate
  from the drive that contains the OS files.
• Evaluate the need for each service installed on
  the OS. Unnecessary services should be turned
  off.
• Assess the patch deployment process. All
  necessary patches should be implemented.
• Unused add-on components should be removed or
  disabled. The rest should be patched regularly.

37
Risks and controls

• Web applications Web applications reside on web
  and/or application servers and provide end users
  with various functionality.
• Web applications can be compromised via a variety
  of ways unless they are programmed really
  carefully.
• Some of the risks/attacks against web
  applications include
• Improper input validation
• Cross-site scripting attacks
• Buffer overflow attacks
• SQL injection attacks
• Improper error handling

38
Risks and controls

• Input validation Web applications implement
  controls to ensure the input entered is valid.
• Web applications expect valid input that is, it
  is of correct length, right type (text vs
  integer), etc.
• Developers often insert edit checks via
  JavaScript that is executed on the client side.
• However end users can always modify these checks
  (since they reside on client side) to bypass them
  and submit wrong inputs to the application.
• At times developers will implement edit checks on
  the server side. However, they have to be
  carefully designed to avoid being bypassed or to
  ensure malicious input is filtered out.

39
Risks and controls

• Input validation risks
• Client side input validation should not be relied
  upon.
• Use server side validation checks as far as
  possible.
• Canonicalize the input (decode all input to
  simplest form) before processing the input to
  avoid attacks that use encoded characters.
• Educate developers about various attacks and
  provide secure programming training.

40
Risks and controls

• Cross-site scripting (XSS) attacks Code
  injection by malicious users into web pages
  viewed by web users.
• Web browsers receive mobile code (say JavaScript)
  from web servers all the time.
• This (JavaScript) code is executed in the browser
  and has access to all objects (cookies, web
  pages, etc.) from that web server.
• This access isnt a problem since the
  (JavaScript) code is provided by the same web
  server that provided the objects too.
• What happens if malicious user is able to provide
  the JavaScript code to the web server, that gets
  sent to the web browser?

41
Risks and controls

• Cross-site scripting (XSS) attacks Code
  injection by malicious users into web pages
  viewed by web users.
• If so the browser will execute the malicious
  JavaScript code as if belongs to the web server
  browser and allows access to all the objects.
  What can this access do?
• It can copy the users cookie (for that web
  site), run local commands (if the web site is
  trusted), or subject user to phishing attacks
  (steal userID and passwords).

42
Risks and controls

• Cross-site scripting (XSS) attacks Code
  injection by malicious users into web pages
  viewed by web users.
• So how is malicious code inserted into web
  servers? This occurs via web applications that
  accept user input without validation. For
  example
• newsgroups web pages may allow a user to enter
  postings (which could contain malicious code) and
  these postings are fed back to other users to
  read, subject them to XSS attack.
• Social engineering attempts wherein user is
  convinced to click on a malicious URL that leads
  to an XSS vulnerable website.

43
Risks and controls

• Cross-site scripting (XSS) attacks Code
  injection by malicious users into web pages
  viewed by web users.
• Several well known websites have been subject to
  XSS attacks/vulnerabilities
• Charles Schwab website
• Hotmail website
• cbs.com
• news.bbc.co.uk
• Paypal website

44
Risks and controls

• Cross-site scripting (XSS) attack risks
• XSS vulnerable websites can lend its users to a
  variety of risks including attackers obtaining
  their credentials, access to their financial
  accounts, disclosure of sensitive data etc.
• Controls
• XSS vulnerabilities are bountiful and need a
  careful review of all code to identify them.
• Provide training to web application developers in
  regarding XSS and secure programming.
• Stringent input validation is required by web
  applications before accepting any input from
  users.

45
Risks and controls

• Controls contd.
• Malicious characters in user input should be
  removed or encoded them (so that the browser
  doesnt interpret is as executable code).
• Disable scripting on browser so malicious code
  doesnt execute.
• Allow only trusted websites to execute code.

46
Risks and controls

• Buffer overflows Attack wherein malicious input
  spills into sensitive portions of memory
  compromising applications.
• Buffer overflows were covered in detail in
  application security chapter. Buffers are memory
  locations allocated by programmers to store
  users inputs.
• Attackers may provide malicious input that runs
  past the size of the buffer.
• Extra input could spill into sensitive portions
  of memory with results ranging from nothing
  happening, to application crashing, to a complete
  compromise.
• Web server software are often impacted by buffer
  overflows attacks.
• E.g. Code Red virus attacked IIS web servers.

47
Risks and controls

• Buffer overflows Attack wherein malicious input
  spills into sensitive portions of memory
  compromising applications.
• In addition, web applications that use
  susceptible third-party libraries can also be
  impacted.
• E.g. Microsofts GDIPlus library was target of
  buffer overflows.

48
Risks and controls

• Buffer overflow risks
• Impact of buffer overflow ranges from application
  failing its execution, to its crash, to running
  of malicious code of attackers choice resulting
  in complete compromise.
• Controls
• Enforce boundary checks before accepting inputs.
  Use compilers that warn of potential overflow
  conditions.
• Educate programmers in safe programming
  practices.
• Use languages like Java (instead of C/C) that
  dont let input easily run past its buffer
  allocation.
• Apply latest patches for third-party libraries.

49
Risks and controls

• SQL injection Attack wherein malicious SQL
  commands are passed into web applications via
  user inputs.
• Web applications with back-end databases are
  often susceptible to these attacks.
• These applications convert user supplied input
  into SQL commands that are processed by the
  database.
• Attackers can craft special input that make the
  SQL commands malicious in nature.
• The database processes these malicious SQL
  commands and end up disclosing sensitive data or
  running sensitive database commands.

50
Risks and controls

• SQL injection SQL injection attack example.
• Consider, a web application, that allows users to
  type in a keyword to search a particular product
  type by asking
• Product keyword antique
• Say, the resulting SQL executed by the database
  is
• SELECT product FROM product_table
• WHERE product_description like antique
• This query results in showing all products from
  the product_table that have the keyword antique
  in it.

51
Risks and controls

• SQL injection SQL injection attack example
  contd.
• Now consider, if the user provides the following
  special input
• Product keyword antique DROP
  table_w_sensitive_data--
• The resulting SQL executed by the database then
  is
• SELECT product FROM product_table
• WHERE product_description like antique
• DROP table_w_sensitive_data --
• This results in display user IDs and password
  hashes and deletion of a table!!

52
Risks and controls

• SQL injection risks
• SQL injection can lead to web application
  malfunction, user impersonation, loss of
  sensitive data, etc.
• Controls
• Do not trust users inputs and sanitize user
  inputs by
• Rejecting known bad data/characters.
• Accepting only valid data.
• Cleaning bad data.
• Dont use dynamic SQL. Instead use bind
  variables or parameterized SQL.
• Minimize privileges of the database application
  user to limit the damage if SQL injection
  succeeds.

53
Risks and controls

• Error handling Web applications return messages
  back to the browser when application errors.
• Web applications will generate errors due to a
  variety of reasons wrong user input, requests
  for resources timing out, invalid database
  queries, invalid logins, etc.
• These errors are meant to either notify the user,
  or as debug messages to help diagnose the error
  condition.
• Attackers can gather a wealth of information via
  these error messages. This includes structure of
  databases, table names, column names, file names,
  directory structure, web server version, valid
  userIDs, etc.

54
Risks and controls

• Error handling Can help attackers gain
  information. For e.g.
• Consider, a web application, that asks users to
  log in and user provides the following
  information
• User jsmith
• Password something
• Application responds Access denied. Wrong
  username.
• Consider, the attacker then provides the
  following
• User admin
• Password something
• Application responds Access denied. Wrong
  password.
• This allows attacker a means to identify valid
  userIDs (since the error message is different).
  The more user IDs the attacker identifies, the
  better chance of finding one with a weak password.

55
Risks and controls

• Error handling risks
• Information leak via error messages allows
  attackers to footprint a web application.
• Controls
• Create standard messages for error handling.
• Send back error codes that dont mean anything to
  attackers but can help developers to debug
  errors.
• Prevent database error messages from returning
  back to users instead send generic error pages.
• Essentially, limit the information that can be
  gleaned from error messages.

56
Assurance considerations

• An audit to assess web security should include
  the following
• Ensure the companys web environment is
  well-defined and documented.
• Evaluate the fortification efforts for the web
  server (operating system security).
• Assess the patch deployment process. All
  necessary patches should be implemented.
• Review the placement of web/application server
  vis-à-vis its business use. Most servers are in
  the DMZ.

57
Assurance considerations

• Evaluate the authentication process for web
  applications. Server-side techniques for session
  management are preferred.
• Ensure the companys privacy statement addresses
  the use of cookies and customer data collected
  via web.
• Determine if browsers used have been patched,
  untrusted sites cant execute mobile code, and
  zones of trust have been defined.
• Ensure that functional plans for backup and
  recovery, business resumption, disaster recovery
  are in place.

58
Recap