4.0

51Web Application Penetration Testing• Maintain restricted access to the share containing the sharedconfiguration and encryption keys. If this share is compromised, anattacker will be able to read and write any IIS configuration for yourWeb servers, redirect traffic from your Web site to malicious sources,and in some cases gain control of all web servers by loading arbitrarycode into IIS worker processes.• Consider protecting this share with firewall rules and IPsec policiesto allow only the member web servers to connect.LoggingLogging is an important asset of the security of an application architecture,since it can be used to detect flaws in applications (usersconstantly trying to retrieve a file that does not really exist) as well assustained attacks from rogue users. Logs are typically properly generatedby web and other server software. It is not common to find applicationsthat properly log their actions to a log and, when they do, themain intention of the application logs is to produce debugging outputthat could be used by the programmer to analyze a particular error.In both cases (server and application logs) several issues should betested and analysed based on the log contents:• Do the logs contain sensitive information?• Are the logs stored in a dedicated server?• Can log usage generate a Denial of Service condition?• How are they rotated? Are logs kept for the sufficient time?• How are logs reviewed? Can administrators use these reviews todetect targeted attacks?• How are log backups preserved?• Is the data being logged data validated (min/max length, chars etc)prior to being logged?Sensitive information in logsSome applications might, for example, use GET requests to forwardform data which will be seen in the server logs. This means that serverlogs might contain sensitive information (such as usernames aspasswords, or bank account details). This sensitive information can bemisused by an attacker if they obtained the logs, for example, throughadministrative interfaces or known web server vulnerabilities or misconfiguration(like the well-known server-status misconfiguration inApache-based HTTP servers ).Event logs will often contain data that is useful to an attacker (informationleakage) or can be used directly in exploits:• Debug information• Stack traces• Usernames• System component names• Internal IP addresses• Less sensitive personal data (e.g. email addresses, postal addressesand telephone numbers associated with named individuals)• Business dataAlso, in some jurisdictions, storing some sensitive information in logfiles, such as personal data, might oblige the enterprise to apply thedata protection laws that they would apply to their back-end databasesto log files too. And failure to do so, even unknowingly, mightcarry penalties under the data protection laws that apply.A wider list of sensitive information is:• Application source code• Session identification values• Access tokens• Sensitive personal data and some forms of personally identifiableinformation (PII)• Authentication passwords• Database connection strings• Encryption keys• Bank account or payment card holder data• Data of a higher security classification than the logging system isallowed to store• Commercially-sensitive information• Information it is illegal to collect in the relevant jurisdiction• Information a user has opted out of collection, or not consented toe.g. use of do not track, or where consent to collect has expiredLog locationTypically servers will generate local logs of their actions and errors,consuming the disk of the system the server is running on. However,if the server is compromised its logs can be wiped out by the intruderto clean up all the traces of its attack and methods. If this were tohappen the system administrator would have no knowledge of howthe attack occurred or where the attack source was located. Actually,most attacker tool kits include a log zapper that is capable of cleaningup any logs that hold given information (like the IP address of theattacker) and are routinely used in attacker’s system-level root kits.Consequently, it is wiser to keep logs in a separate location and not inthe web server itself. This also makes it easier to aggregate logs fromdifferent sources that refer to the same application (such as thoseof a web server farm) and it also makes it easier to do log analysis(which can be CPU intensive) without affecting the server itself.Log storageLogs can introduce a Denial of Service condition if they are not properlystored. Any attacker with sufficient resources could be able toproduce a sufficient number of requests that would fill up the allocatedspace to log files, if they are not specifically prevented from doingso. However, if the server is not properly configured, the log files willbe stored in the same disk partition as the one used for the operatingsystem software or the application itself. This means that if the diskwere to be filled up the operating system or the application might failbecause it is unable to write on disk.Typically in UNIX systems logs will be located in /var (although someserver installations might reside in /opt or /usr/local) and it is importantto make sure that the directories in which logs are stored are in aseparate partition. In some cases, and in order to prevent the systemlogs from being affected, the log directory of the server software itself(such as /var/log/apache in the Apache web server) should bestored in a dedicated partition.This is not to say that logs should be allowed to grow to fill up the filesystem they reside in. Growth of server logs should be monitored inorder to detect this condition since it may be indicative of an attack.Testing this condition is as easy, and as dangerous in production environments,as firing off a sufficient and sustained number of requeststo see if these requests are logged and if there is a possibility to fillup the log partition through these requests. In some environmentswhere QUERY_STRING parameters are also logged regardless ofwhether they are produced through GET or POST requests, big que-