Docstoc

Web Based Applications

Document Sample
Web Based Applications Powered By Docstoc
					Audit Guide for Web Based Applications
Draft 1.1 July 2001



Web Servers

The World Wide Web (WWW) provides a mechanism to link pages with content to
other related pages over the existing Internet. Currently, most of the web servers
provide read access to a file system of HTML files (static content) or a database
serving active content. Active content uses interpreted and binary code that executes
on the browser. Commercial Web servers have become very large complex code
bases.


Java and JavaBeans

Java is a programming language developed at Sun Microsystems to program
consumer products. First launched in 1995, it was in 1996 that Java really gained
strength. Java is loosely based on C++. It was stripped down to a bare minimum in
order to be compatible with the limited space the chips in handheld devices would
offer, and was designed to allow programmers to more easily support dynamic,
changeable hardware.

Java is 80% compiled and 20% interpreted language. Its portability is achieved by
generating bytecode that is executed at run time. Java applets are bytecodes that are
downloaded and executed within a browser. Most browsers and servers support Java
rutime interpreters and just-in-time compilers.

JavaBeans is Sun's component architecture and API set for building reusable Java
components. The JavaBeans component model provides component interface
publishing and discovery, event handling, persistence, layout, and application-builder
support. Using JavaBeans, developers will define independent components that can be
reused in a variety of ways to create new browser, and even non-browser,
applications.

ActiveX and Active Desktop

ActiveX is Microsoft's component strategy for building Windows applications and
browser-based applets. ActiveX is based on Microsoft's Object Linking and
Embedding (OLE) object standard and Component Object Model (COM). ActiveX
enables software components to interact with one another in a networked
environment, regardless of the language in which they were created. ActiveX
uses binary object code instead of Java's bytecode that is downloaded into browsers.
JavaBeans and ActiveX are competing for the same computing space.

An Active desktop utilizes ActiveX on the desktop (browser) and server (Active
Server). Microsoft's Internet Explorer browser incorporates this technology. This will
allow the browser to pull and push data depending on the applications. The Active
server stores a user's personalized information. When certain
business events transpire (e.g., new mail messages, document updates) the browser is
notified and selects the proper function.




                                           1
Audit Guide for Web Based Applications
Draft 1.1 July 2001



Intranet Shortcomings

Since most computer security statistics show that over 80% of all computer related
fraud is committed by insiders, the Intranet threat is higher than from the Internet. A
properly administered commercial firewall with a stringent security policy and some
ancillary products will combat most Internet threats (e.g., hacking, denial-of-service,
virus software). The real security problem with most corporations is inside the
firewall. Insiders often have a motive to strike against a company. Insiders often have
direct physical access to the computer and familiarity of the resource access controls.
The principle threat at the application level is the abuse/misuse of authority by
authorised personnel. The network level threat is due to the fact that the insider has
physical access to the LAN that provides him/her with the ability to view sensitive
data traversing the network (e.g., man-in-the-middle attack). Although insiders cause
more damage than hackers do, the external hacker problem remains serious and
widespread.

CGI scripts written in interpreted rather than compiled languages, such as PERL or
shell scripts, are particularly vulnerable to hacking, because they can be fed
misleading statements. By submitting unanticipated input data to a CGI script,
hackers can get the server to mail them password files, set up Telnet sessions to
secure resources, or gain access to useful configuration information.

Intranet web technology is ideal for giving users quick, easy access to internal
documents and data. The openness of the technology means that special care must be
taken to ensure that the wrong people don't get into unauthorised information or
applications. The web technology does not provide the adequate mechanisms to
control access to corporate information. This is due largely to the stateless nature and
lack of security mechanisms to perform proper access control delegation (i.e., end to
end security). The web server is not acting on behalf of the user, but as a single
superuser to access back-end legacy systems.

Client-server vs. Web

Traditional client-server development environments can rely on persistent connections
between clients and servers. Web communications using HTTP are intermittent,
meaning that they are constantly being established, torn down and reestablished as the
browser requests pages and objects over the network. This makes keeping state
between requests next to impossible. Alternative methods, like cookies and modified
URL links, are all that technology offers at the present time. This lack of connection
state is a major security limitation with HTTP.

Currently, the HTTP protocol only supports basic authentication (cleartext username
with an uuencoded password). HTTP roots are from the Internet; hence, it offers no
more security than the current suite of Internet applications (e.g., FTP, TELNET, and
SMTP). Each time a web page is accessed which requires authentication, the web
server performs an authorisation check. If an empty authorisation header field is sent
(status code 401-Unauthorized), the user is prompted for a username password pair.
The browser caches the authorisation information locally for each given URL realm.
This allows users to authenticate once for a given resource.


                                            2
Audit Guide for Web Based Applications
Draft 1.1 July 2001



Most modern client-server applications (SAP, Novell, and NT Server) use encrypted
passwords and strict access control binding.

Delegation of Authority

The delegation of authority is the process of transferring authority to a given principal
in order to perform a certain action that requires access control. Authorisation
specifies the resources that are to be accessible to a principal (e.g., user, process, role,
and job title). A resource could be a transaction, account, menu, or something one
wants to protect. The user and/or process that request access to a resource is defined
to be a principal. An access control list (ACL) is associated with each resource, listing
the individuals (principals) authorised to access the resource along with the access
rights authorised (e.g., query, debit, and trade). An ACL manager processes the
request from the principal and compares it to the resource's ACL.

Currently, in the WWW technology no one is addressing authorisation in a standard
fashion. Most authorisation is performed at the operating system level (e.g., file, and
directory) and at the DBMS level (e.g., tables). This requires web application
developers to have to develop specific security code to provide a finer granular access
to corporate resources. The benefit of this standard is to provide application
developers with a common authorisation API that will allow them to get the same
security level without writing specific code. This will allow application quicker time
to market, and ease of maintenance.

Most authorisation decisions are based on a relationship with a given principal name.
This name could be part of a role (e.g., group) for a given job title within an
organisation. In most cases, access to resources is not performed from a principal
name, but from a job title or role name. Associative access control mechanisms
consists of resource Access Control Lists (ACLs) or user capability lists (i.e.,
resources a user has access to). This access decision is based on the permission(s)
(e.g., credit, debit, and rwed) that is derived from the intersection of the resource and
role pair. An ACL consists of roles and permissions for a given object. Conversely, a
capability list consists of resources a role has access to.

Logical access control is based on the accumulation of a given action over a period of
time (e.g., thresholds, sequences, or some logical combination). It is assumed that an
associative check will be performed before the logical. This will allow organisations
to limit principal's access based on credit or trade limits, or necessary sequences to
complete a transaction (e.g., bank authorisation before purchase).



Active Content Problems

Remote distribution and execution of software on the Intranet is less risky than on the
Internet. Java, JavaBeans and ActiveX are paving the way for this technology. Most
of the security concerns with this technology stem from source code authentication
and verification. This is a major problem on the Internet because it is hard to trust
sites one doesn't control, and most of the code is largely anonymous. Since most


                                             3
Audit Guide for Web Based Applications
Draft 1.1 July 2001

firewalls filter inbound traffic only, this poses a big problem for corporate networks.
If some rogue software infects a browser than all of the keystrokes and data could be
sent outbound over the Internet. Sun just announced that the next version of Java will
support source code authentication.

ActiveX is a binary object code based on OLE that runs inside the browser. ActiveX
is not constrained by the browser. Once it is enabled, it can perform any operation that
an OLE-based application can perform. The difference between executing client
applications and ActiveX are negligible. ActiveX runs a lot faster than Java but
nothing protects it from wrecking havoc on your desktop, an example of this is an
ActiveX control called Exploder which can shutdown Windows 95.


Intranet Security Solutions

A corporate security policy is the foundation upon which all Intranet information
security related activities are based. In order for a security policy to be effective, it
must receive senior management approval and support. The security policy must keep
the technological pace of the information systems technology, which allows access to
corporate resources. The corporate security policy must balance the organisation's
operational requirements with the state-of-the-art in security solutions. Since both of
these are under constant change, the policy must stay current.

Before corporate resources can be protected, it must first be understood what is being
protected and why. The what is derived from data classification of corporate
proprietary data (e.g., very confidential, confidential, internal, and public). The why is
based on how important (i.e., value) the information is to the corporate officers, and
what would be the cost and/or effect of loss.

All information security plans should encompass four major aspects of information
security: 1) physical (e.g., physical and procedural controls to corporate resources), 2)
network (e.g., network isolation [firewall], packet encryption), 3) platform (e.g.,
intrusion protection and compliance monitoring tools), and 4) application security
(strong authentication, privilege management, electronic commerce).

SSL




                                            4
Audit Guide for Web Based Applications
Draft 1.1 July 2001

Secure Socket Layer (SSL) is a scheme proposed by Netscape. It provides a low level
encryption scheme used to encrypt packets in higher-level protocols such as HTTP,
TELNET and FTP. SSL v2.x includes provisions for server authentication (i.e.,
verifying the server's identity to the client), encryption of data in transit. SSL v3. X
includes an optional client authentication (e.g., verifying the client's identity to the
server). The key pair used for client authentication will also be used for secure email
(e.g., SMIME).



Authorisation

To properly design authorisation into an enterprise one has to employ some basic
security concepts of "separation of duties", "least privilege", and "individual
accountability". Separation of duties is the practice of dividing the steps in a critical
function (e.g., approving monetary transactions, audit reviews, wiretap approval)
among different individuals. The least privilege principle is the practice of restricting
a user's access (to data files, processing capability, or peripherals), or by type of
access (read, write, execute, delete), to the minimum necessary to perform the job.
Individual accountability consists of holding someone responsible for their actions.
Accountability is normally accomplished by identifying and authenticating users of
the system and subsequently tracing actions on the system to the user who initiated
them. The problem is integrating security mechanism into the existing Intranet design.

Products like NeTegrity's SiteMinder addresses fine grained access control of
corporate resources (i.e., authorisation). SiteMinder also includes a secure
administration interface that stores all the user's security related attributes in an SQL
DBMS.

Active Content Solutions

The browser must control all active content processing. This includes regulating the
download, enabling of ActiveX controls or external plug-ins, and executing ActiveX
scripts and Java. Browsers must also control from who and where they accept
software (i.e., trusted sites and software publishers). This is accomplished by the
browser storing the public keys of the sites and by digitally signing the active content
before it downloads. If code is not signed, the browser by default should not
download it.

Browsers protect themselves from Java using a strict applet sandbox-style security
measure that resides in the Java virtual machine. The enforcement happens after the
bytecode downloaded, verified, and instantiated by the class loader. The Applet
security manager takes over monitoring all operations from this point. The Applet
security manager is established at startup, and it cannot thereafter be replaced,
overloaded, overridden, or extended. Applets cannot create or reference their own
security manager. Applets are also prevented from reading and writing files on the
client file system, and from making network connections except to the originating
host.




                                             5
Audit Guide for Web Based Applications
Draft 1.1 July 2001

Microsoft's Authenticode addresses this risk by identifying who published the
software before it is downloaded, and verifying that no one tampered with it before or
during the download process. This still does not solve the problem of introducing
malicious code into the browsers (e.g., virus, or Trojan horse). Be on the look out for
an online virus scanner for ActiveX controls. Other than the aforementioned
techniques, the only way to control ActiveX is through procedural means (e.g.,
security awareness training).



Network Security Controls

Application security must be robust enough to thwart network sniffing. Due to the
infancy of the Intranet technology and its roots from the Internet, a network topology
can be constructed to alleviate some of the risk. Intranet firewalls, Ethernet-switching
hubs that support virtual LAN and partitioned LANs are some of the options. By
placing firewalls at strategic points between department's access to Web pages and
Web-based applications between departments can be effectively limited. Most
networking equipment vendors are offering firewall-like capabilities within their hubs
and routers, expressly for enhancing intra-enterprise security.




                                           6
Audit Guide for Web Based Applications
Draft 1.1 July 2001




MANAGEMENT OF E-COMMERCE

No.   ICQ
      Strategy
      Is there a business, marketing and technology strategy?
      Has the feasibility been assessed?
      Have goals, success factors and return on investment been assesed?
      Are delivery timescales realistic?
      Service
      Have Service Level Agreements been produced detailing:
              Availability
              Time to fix
              Time to implement changes
              Back ups
              Volume based throughput
              Security

      Training
      Has a security awareness training and education program been implemented?




WEB BASED APPLICATIONS

No.   ICQ                                                                                          
      Is unnecessary disclosure of information avoided?
      Review the source of HTML, JavaScript and other client-side scripting languages to
      ensure that these do not contain unnecessary information that could be observed and
      exploited by potential attackers. This might include:
          developer names (could be used for social engineering)
          disabled functionality
          details about Common Gateway Interface (CGI) functions and parameters
          third-party tools in use, which may be vulnerable.
      Review error messages returned by the web-based application to ensure that they do
      not reveal undesirable information.
      Has a robust logon process been implemented?
      Where a web-based application requires users to log on to authenticate themselves,
      consider the following
      factors in designing the process:
          log-on failure messages should not indicate which of the username/password pair
           submitted was incorrect
          where http basic authentication is used, there is no account lockout after
           successive failed attempts and applications may therefore be vulnerable to brute-
           force attacks
          where account lockout is implemented, further log-on failure messages should be
           carefully designed (for example, to avoid revealing when the password has been
           guessed correctly, even though the account is locked)
       avoid allocating system resources for a potential user session before authentication
           is complete: thus reducing the scope of denial of service attacks based on initiating
           many log-on attempts.
      Are sessions appropriately tracked?
      Web-based applications often need to implement mechanisms to track transactions
      within a user session as the underlying http protocol cannot do this (it is stateless).
      When these mechanisms are designed, the following factors should be taken into
      account to minimise the risk of sessions being hijacked or cloned:



                                                   7
Audit Guide for Web Based Applications
Draft 1.1 July 2001

          avoid using mechanisms that can lead to session IDs being unnecessarily
           disclosed (see, for example, the
          sections covering GET/POST and Cookies below)
          avoid session IDs that are easily predicted by including a random element.
      Are Session Timeouts Implemented?
      Implement session timeouts for web-based applications after designated periods of
      inactivity if there is considered to be a risk from access to unattended browsers.
      Are Sessions Encrypted where required?
      Consider using secure session protocols such as SSL to encrypt sessions between
      browsers and the web server to prevent sensitive application data being intercepted.
      Are GET / POST operations carefully implemented?
      Use http POST rather than GET operations to obtain information from users that may
      be sensitive, personal or compromise the security of the application.
      URLs requested by GET operations are stored in the browser’s history file and can also
      be passed on to other web servers via the http Referrer field. This can lead to the
      disclosure of sensitive information. For example, the following GET operation could
      cause damaging information to be stored in insecure log files:
      http://www.anybank.com/scripts/login.cgi?username=john&password=partyhat
      Are hidden form fields restricted?
      Avoid using HTML hidden form fields to pass important or sensitive parameters from
      browsers to web servers.
      These fields, although not displayed in web pages, can easily be viewed by users (by
      viewing the HTML source) and modified to cause unexpected results. An example of
      the typical use of hidden form fields to avoid is shown below.
      <INPUT TYPE="hidden" NAME="username" VALUE="lennonj">
      <INPUT TYPE="hidden" NAME="password" VALUE="yellowsubmarine ">
      <INPUT TYPE="hidden" NAME="adminflag" VALUE="no">
      Are Cookies carefully controlled?
      Where cookies are used to pass important or sensitive information between browser
      and web application, make sure that cookie parameters are set to avoid unnecessary
      disclosure of the information.
      The structure of a cookie is shown below.

      PARAMETER / MEANING
      NAME / Arbitrary string used to identify the cookie, since a web server can send the user
      more than one cookie
      DOMAIN / The range of hosts where the browser is permitted to transmit the cookie
      PATH / The range of URLs where the browser is permitted to transmit the cookie
      EXPIRES / When the browser must no longer store the cookie
      SECURE / Boolean value that indicates if the browser may only send the cookie over an
      encrypted session
      DATA / Arbitrary strings of text

      Users can examine the contents of cookies stored on their PCs. Even those which
      expire at the end of the session can be viewed by typing:
      JavaScript:alert(document.cookie) into the browser URL field.

      Some users prevent their browsers from accepting cookies causing problems for
      applications that depend on them.

      Is User Input Validated?
      Validate data returned from browsers to check for unexpected values that could cause
      the application to behave in unintended ways. Particular things to check include:
          values falling outside allowed ranges
          volume of data returned outside expected ranges
          special characters that could be misinterpreted by the application, for example:
               %0A new line character (in hex)
               | pipe
               ; semicolon
               “ double quote
               ‘ single quote
               <% %> VBScript terminators
      Do not rely on client-side filtering of user input (for example,, using JavaScript) as this
      can be circumvented by the user.
      Are Scripts Carefully Constructed?
      Common Gateway Interface (CGI) scripts are used by web-based applications to



                                                     8
Audit Guide for Web Based Applications
Draft 1.1 July 2001

      communicate with resources, such as back-end systems and internal databases. They
      are prone to subversion and are a primary target of attackers. The following measures
      are recommended:
          Store all CGI scripts in a single, separate directory, for example, cgi-bin under the
           web server home directory.
          Only accessible by valid administrators
          Do not include any command processors or interpreters such as Perl or
           command.com in the CGI directory.
          Validate all client-side input to CGI scripts (see Validate user input above).
          Check for potential vulnerabilities in all CGI scripts using tools, such as:
                    CGIWrap (to force scripts to run as users, not as web server owner)
                    TaintPerl (to prevent passing of unchecked input to system calls)
                    phf and Latro exploit test programs.
          Allocate sufficient memory for CGI scripts to minimise the likelihood of a buffer
           overflow.
          Ensure CGI scripts record a log of what they have done.
       Avoid using SUID shell scripts within UNIX. Use APIs or compiled programs, where
           possible, and test them thoroughly or use existing tried and tested code.
         Scripts should only be written by experienced script programmers?

      Has security of the application, web server and web host been checked
      before going into production?
      Are scripts thoroughly tested to avoid subversion including attacks using buffer
      overflow techniques and embedded commands?
      Do scripts that allow users to send mail only use secure mail programs (e.g.
      /usr/lib/sendmail and not /bin/mailx or /usr/ucb/mail)
      Are 'forms' avoided as any script can be called directly by entering its URL with an
      embedded list of parameters?
      Are Microsoft ISAPI scripts only held in execute only directories that web users cannot
      read or modify?
      Have correct access permissions been set on web directories and the pages and scripts
      they contain?

      Is the Application Architecture Secure?
      Does back-end connection to a database avoid use of privileged user-ids?
      Does connection to a database avoid use of hard-coded passwords? Or
                Are any hard coded passwords held in obscure places?
                Are hard coded passwords lengthy & cryptic?
                Are hard coded passwords held and on files adequately protected?
      Is the web server run on a physically different server from the backend application
      server?
      Is sensitive customer data (ie credit card detail) encrypted?
      Are users prevented from calling backend objects directly? (e.g. by allocation of
      session id following successful login and encryption of link between web server and
      back end data server)




                                                    9
Audit Guide for Web Based Applications
Draft 1.1 July 2001

WEB SERVER SOFTWARE

Organisations have a wide choice of web server products ranging from commercial
offerings such as Microsoft’s IIS and Netscape’s Enterprise Server (SUN iPlanet) to
public domain or ‘open source’ products such as Apache. Different web servers have
different security features and these should be considered in selecting an appropriate
product. However, other factors will have a major influence on the choice of web server
software such as:
• choice of web host (for example, UNIX or Windows NT)
• cost of purchase and support
• skills and experience within the organisation.

No.   ICQ
      Is unnecessary disclosure of information avoided?

      Avoid unnecessarily providing potential attackers with information that could help them
      to find weaknesses in web sites:
      Suppress, if possible, the Server field in HTTP headers that identifies the web server’s
      brand and version.
      A facility provided at the http://www.netcraft.com site uses this field to undertake an
      automated survey of web servers in use.
      Ensure that directories of files on the web server are not indexable as this can reveal
      the presence of files not intended to be publicly accessible.
      Ensure that the source code of server-side executables and scripts (for example, CGI
      scripts and ASP files) cannot be viewed via a web browser.
      Where a web server supports a certification authority component, allowing users to
      obtain personal certificates on-line, ensure this component is configured to avoid
      disclosing information about other certificates issued.

      Are web servers containing sensitive pages run on alternate ports and is access
      restricted by the packet filter?

      Is any sensitive information removed from public web servers?

      Are sensitive pages secured by password or access list?
      The Microsoft Certificate Server can reveal details of all requested and issued
      certificates via an interface accessed by: http://site-name/CertAdmin/wcaForm.asp
      Are known server bugs removed?
      Ensure that the web server software in use incorporates vendor-issued updates and
      patches to remove known security problems.
      Ensure a process to receive notification of any newly detected security vulnerabilities in
      web server software so that risks can be understood and managed is implemented.
      Vendors' web sites can be a good source of information on security problems that have
      been fixed but may not provide notification of known but unresolved problems. Internet
      news groups and mailing lists will usually provide the most current information
      Are Users Appropriately Authenticated?
      Consider employing user authentication, supported by all web servers, to control access
      to specific web pages. The main options for implementing user authentication are
      outlined in the following table.

                                   Advantages                           Disadvantages
Basic Authentication - based on    Supported by all web servers         Traditional disadvantages of
simple username / password         and browsers as a standard           fixed password schemes:
                                   feature of HTTP.                     passwords may be easily
                                   Well understood by users.            guessable administrative impact
                                                                        of users forgetting passwords
                                                                        passwords in clear on the
                                                                        Internet.
NT Challenge / Response            Employs encrypted                    Only supported by Microsoft IE
                                   challenge/response to avoid          browsers.



                                                   10
Audit Guide for Web Based Applications
Draft 1.1 July 2001

                                   passwords in clear. Suitable for
                                   intranets where types are
                                   controllable.
Certificate Based                  Based on cryptographic digital      Requires use of in-house or
                                   certificates and avoids             outsourced certification
                                   passwords in clear. Can be          authority. Administrative impact
                                   more transparent for users.         of issuing and
                                                                       revoking certificates.
Token based                        Provides strong, two-factor         Token management needed by
                                   authentication. Usually employ      both users and organisation.
                                   one-time passwords that protect     Cost of tokens.
                                   against password interception.




      Are FTP services carefully Implemented?
      Avoid running an FTP service that allows users to upload files on the same host as the
      web server, as this can result in arbitrary material being transferred to the host.
      If an FTP service is a necessity consider the following approaches to protect the
      integrity of the web server:
          use the access control capabilities of the web server to place strict limits on the
           directories and files that can be accessed via FTP
          use strong authentication for FTP PUT operations, such as SSL-based digital
           certificates
       allow PUT access only through a separate server instance, run under a separate
           user ID that cannot be read by 'nobody'. (The user ID for normal access should not
           have write access to the document files.)
      Logging
      Is logging of access to web pages enabled and are logs reviewed?


For further information on Web server security consult the following
NT IIS audit guide
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/iischk.asp

Sun iPlanet documents
Description of obj.conf http://docs.iplanet.com/docs/manuals/enterprise/41/nsapi/02_objcn.htm#13061

Variables in magnus.conf
http://docs.iplanet.com/docs/manuals/enterprise/41/nsapi/0b_magnu.htm#17150

Basics of iPlanet operation
http://docs.iplanet.com/docs/manuals/enterprise/41/nsapi/contents.htm

IPlanet administrators guide
http://docs.iplanet.com/docs/manuals/enterprise/41/ag/esabout.htm#1005439

Netscape Enterprise (iPlanet) checklist
http://www.usenix.org/sage/sysadmins/solaris/webservers/netscape.html#install



WEB HOST


Although a number of platforms are available for a web server, for many organisations
the choice is essentially between UNIX and Windows NT. This choice will be influenced
by:
• the type of web service required


                                                  11
Audit Guide for Web Based Applications
Draft 1.1 July 2001


• the availability of in-house resources
• organisational preference for UNIX or NT.

      Has Hardware Been Carefully sized?
      Carry out a careful capacity planning exercise to ensure that the CPU, memory and disk
      resources of the host system are sufficient for the expected usage.
      Monitor actual usage of the resources over time. This will allow upgrades to be applied
      in advance of any serious degradation in performance.
      Is Resilience Built in?
      Use well-tested and reliable hardware platforms with in-built redundancies geared
      towards the levels of availability required. for example: web hosts can be provided with
      redundancy in:
           power supplies
           CPUs
           disk drives
       entire systems: in hot-standby mode at an alternative location.
      Is Physical Security Adequate?
      Locate web servers in a managed and secure physical environment to protect them
      from threats such as fire, accidental damage and vandalism.
      Configure the Operating System Carefully (Harden it!)
      Are all user accounts except for the web server account(s), web master accounts and
      authorised administrator account removed?
      Are different root directories for the web server and server documents used?.
      Locate interpreters, shells, and configuration files outside the web server directory.
      Use a dedicated host for the web server and aim to disable all other services, including
      SMTP and FTP.
      Ensure only a minimum set of client applications is installed. If a browser must be
      installed, then downloading of active content (for example, ActiveX and Java) should be
      disabled.
      Where appropriate, run multiple server instances under different IDs to provide different
      types of access to different users.
      Install packet filters, such as TCP wrappers, to restrict connections from known hosts or
      services and to log incoming service requests.
      Are all sensitive files protected from access through the web e.g. /etc/passwd, data files
      etc?
      Unix
      Is ‘chroot’ used on web server root to prevent the web server from seeing any part of
      the normal file system?
      Is web server started as root user (to open standard ports: 80/443) and then changed to
      another user ID, for example, www, with minimum privilege?
      Remove default accounts (for example, lpd and sync) and minimise the number of
      privileged accounts.
      Remove compilers, setuid/setgid scripts, and windowing software.
      Do not run routed (so that the host’s router tables are not automatically updated). Set
      the default route to be the access router.
      Disable all services not explicitly required, including NFS, NIS, other RPC-based
      services, the portmapper, booting services, the ‘r’ command services, UUCP, and
      printing.
      Disable unnecessary kernel services, in particular, the IP forwarding (routing) option
      and any services that enable sniffing (for example, tcpdump).

      See Unix Audit guide for further information on controlling Unix systems
      NT
      Use only the NT File System (NTFS).
      Disable, if possible, both the server and workstation on the host platform.
      Do not designate the server to be a domain controller. This will prevent an attacker who
      compromises the security of the web server from gaining domain level access.
      Do not allow the web server to run as SYSTEM.
      Rename the administrator account to an obscure name, so that an attacker would have
      to first guess the account name. Disable the guest account and all user accounts.
      Disable all unnecessary network services and protocols.
      Remove any bindings to NetBIOS over TCP/IP.




                                                   12
Audit Guide for Web Based Applications
Draft 1.1 July 2001

      See NT Audit guide for further information on controlling NT systems
      Are Robust server admin practices implemented?
      Restrict, where possible, the administrator account to log in via the console only. If this
      is not possible, the remote administrator log-in should be subject to strong
      authentication (for example,, one-time password or challenge/response).
      Log the failures and successes of administration operations, log-ins, security
      configuration changes and server initialisations and shutdown.
      Consider using tools such as SSH to encrypt administration sessions to prevent
      information such as administration passwords being disclosed.



NETWORK ENVIRONMENT
The web server clearly needs connectivity with the Internet and often also requires access to or from
the intranet. The way these connections are established can not only influence the security of the web
server and web application but also that of the organisation’s entire IT infrastructure. The network
environment of web servers therefore needs to be designed and managed carefully. Some of the main
issues to be addressed are identified in the following checklist.

      Have bandwidth requirements been estimated?
      Carry out a careful bandwidth estimation exercise and monitor utilisation frequently.

      NB This is one of the most critical factors in preventing overload
      Is resilience built in?
      For systems with particularly high availability requirements, consider maintaining a
      separate Internet connection through a different Internet Service Provider.
      Have Network Services Been Restricted?
      Limit the services allowed between the web server and the inner network to those that
      are justified by a specific requirement.
      Do not permit the server to initiate network connections, but only to receive and respond
      to connection requests.
      Permit port 80 (and/or port 443 for SSL) connection from outside with ACK bit NOT set
      and deny all others.
      Permit port >1023 connection to outside, in response to above, with ACK bit set and
      deny all others.
      Have Networks been carefully configured?
      Locate the web server on a network that does not carry confidential traffic, preferably on
      a network of its own, a switched Ethernet or an ATM network to minimise the risk of
      packet sniffing.
      Make a careful assessment of the best placement of the web server in the network
      architecture.

      The key points to consider are outlined in the following box.


                                    Advantages                            Disadvantages
On external network                 Least risk to security of internal    Least control/flexibility
                                    networks                              Poor opportunities for integration
                                    Greatest web server                   with other corporate systems
                                    performance                           Only supports a basic web
                                    Low manpower costs                    service
                                    Particularly suitable for small
                                    organisations
Outside firewall                    Low risk to security of internal      No protection of web server by
                                    networks                              firewall
                                    Increased control and flexibility     • Increased manpower costs
                                                                          • Increased
                                                                          • hardware/communications
                                                                          costs
Inside firewall                     Good protection of web server         Increased design complexity
                                    by firewall                           Increased
                                    Good opportunities for                hardware/communications
                                    integration with other corporate      costs
                                    systems
                                    Good control and flexibility



                                                    13
Audit Guide for Web Based Applications
Draft 1.1 July 2001

On internal network                 Web server protected by firewall     Greatest risk to internal network
                                    Greatest control and flexibility     Possible threat from internal
                                    Suitable for intranet server         users



MANAGEMENT PRACTICES


Although technical measures such as those described above are essential, the security of a
web site is also dependent on effective management practices. This section outlines the
measures that should be considered in the following areas:
• capacity planning and monitoring
• security maintenance
• change management
• security monitoring
• event logging
• intrusion detection
• incident management.

      Has a capacity monitoring process been implemented?

      Establish an overall capacity planning process for web sites, observing the following
      principles:
           ensure hardware platforms and communications links are readily scaleable to
            respond to increases in demand without fundamental changes in architecture
       establish monitoring processes to measure usage of the physical resources and
            communications bandwidth so that upgrades can be arranged before capacity
            overloads become problematic.
      Are potential security problems identified?
      Identify sources of information on new security vulnerabilities in the technology being
      utilised (for example,, CERT, NTBUGTRAQ and other mailing lists, supplier web sites -


      Establish a workable and reliable change control process with event logging and
      reporting procedures to ensure that updates are made in a safe and timely manner.
      Monitor the list of the currently available service packs and hot-fixes on the web sites of
      product vendors to ensure that the most recent versions are in use.
      Test hot-fixes before installation.

      NB Hot-fixes to NT are now supported by Microsoft but not regression tested to the
      level of Service Packs.
      Install hot-fixes in the correct order.

      Are changes managed effectively (hardware, software & content)?
      Document the change management process and ensure that its scope is clearly
      understood.
      Establish a formal mechanism for identifying the security impact of changes and ensure
      that this is evaluated by a qualified individual.
      Implement an approval process, clearly identifying the sign-offs required for changes to
      take place.
      Record all controlled changes in a comprehensive and consistent manner.
      Ensure contingency plans are prepared
      Is Security Monitored
      Conduct regular and frequent checks to ensure web site components continue to
      adhere to the agreed configuration standards required for security.
      Carry out a 'baseline review' before a web site is initially connected to the Internet and



                                                    14
Audit Guide for Web Based Applications
Draft 1.1 July 2001

      compare subsequent reviews with this baseline to detect changes.
      Check that web site components are not vulnerable to newly emerging threats.
      Conduct active 'penetration' testing to simulate external attacks on web sites.
      Use automated tools to support monitoring where possible.

      Is an effective logging process implemented?
      Develop an audit/event logging procedure that preserves the integrity of logs by taking
      the following points into consideration:
          routinely back up all logs to a directly attached device
          keep logs (and spool directories) on dedicated disk partitions to reduce the effect of
           them filling up the rest of the system
          use drop-safe logging, where the audit/event records are transmitted from the host
           to a dedicated PC via a serial link or to protected media such as a WORM disk
          use the publicly available TCP wrapper software to provide detailed logs, for
           example of connection requests received by the bastion host
          determine what action should be taken when the capacity of the logs has been
           reached: for example,
                schedule frequent checks of disk usage and automatically page the
                administrator when the device is approximately 90% full.

      In extreme cases, it may be desirable to halt the entire system to avoid unlogged
      activity. However, this action will make the system vulnerable to deliberate denial of
      service attacks.
      Is Appropriate information logged?
          log-on and log-off success and failure
          restart, shutdown and system success and failure
          security policy changes success and failure
          user and group management success and failure
          file and object access success and failure
          use of user rights success and failure
          departures from ‘normal’ usage patterns such as:
          system load at different times of the day
          number of processes running
          CPU utilisation
          unusual successes/denials of connections
          success and error messages from both firewalls
          multiple access attempts
       access to unusual ports.
      Is Intrusion Detection Implemented?
      Implement an intrusion detection process adopting the following principles:
          use a respected commercial package that is regularly updated to keep up with new
           vulnerabilities and attacks
          keep the intrusion detection tool up-to-date by applying the latest patches and
           attack signatures
          run the absolute minimum of services on the platform hosting the intrusion
           detection tool
          do not allow the platform’s interface to be visible to the perimeter networks being
           monitored
          establish an administration and reporting network for the intrusion detection system
           that is isolated from the internal network
       do not place too much reliance on the intrusion detection tool and ensure other
           security procedures are in place.
      Is incident management implemented?
      Implement an effective process for dealing with security incidents. This could be based
      on the following six
      steps:
      1. Prepare: Develop and document the response plan and identify the staff, tools and
      external resources that may be required.
      2. React: Put the plan into action by assessing the severity of the incident and
      establishing management control.
      3. Respond: Gather the appropriate resources to tackle the incident and gather
      information.
      4. Contain: Identify and remove the cause of the incident and improve defences.
      5. Recover: Restore the system (from backups if necessary) and verify that
      vulnerabilities have been removed.



                                                   15
Audit Guide for Web Based Applications
Draft 1.1 July 2001

      6. Follow-up: Review controls in the light of the incident and confirm the effectiveness of
      incident detection and response processes.
      Is adequate support provided?
      Ensure that adequate resources are in place to support the incident management plan.
      These are likely to
      include:
          incident response team leaders and team members with high levels of technical
           skills
          ready access to external agencies for back-up support
          readily available hardware and software for incident investigation
       training courses, checklists, guidelines and procedures.



OUTSOURCING ISSUES

Although many organisations will maintain their own web sites on their own
networks, outsourcing is an approach that is commonly adopted for web
servers, often because of a lack of the appropriate technical skills within the
organisation. The typical options available for outsourcing web sites include:

Own machine on provider network                         This model is referred to as server co-
                                                        location. The owner is responsible for
                                                        providing a fully-configured web server,
                                                        which is located in the service provider’s
                                                        facility with a high-speed connection
                                                        to the Internet.
Rent space on shared machine on provider                Many providers offer the service of rented
network                                                 disk space on a shared web
                                                        site for a monthly fee. Individual renters
                                                        are only responsible for
                                                        maintaining the information to be
                                                        accessible from the Internet. This is
                                                        common for small companies where the
                                                        equipment and skills required
                                                        for a dedicated web site cannot be justified.


Organisations contemplating outsourcing of web sites should give consideration to how
the following issues will be addressed and, where necessary, contractually agreed:
• establishing security targets and linkage to a risk/reward policy
• identifying how security monitoring will be conducted and reported
• assessing the security of the third party’s network architecture
• assessing the third party organisation’s security practices and culture
• identifying the third party’s ability to respond to new vulnerabilities
• identifying the third party’s ability to respond to security incidents
• identifying data backup and disaster recovery requirements
• implementing secure mechanisms for remotely updating web site content
• establishing the right to conduct security tests and reviews.

                                                   16
Audit Guide for Web Based Applications
Draft 1.1 July 2001




                                         17

				
DOCUMENT INFO