Protecting Web Applications and Users

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Protecting Web Applications and Users"

Transcription

1 Protecting Web Applications and Users Technical guidance for improving web application security through implementing web browser based mitigations. Defence Signals Directorate February 2012

2 Contents 1 Introduction Leveraging Browser-Based Security Controls Content Security Policy Implementing a Content Security Policy CSP Implementation Considerations Further Information HTTP Strict Transport Security Example of HSTS in action Implementing HTTP Strict Transport Security HSTS Implementation Considerations Further Information Frame Options Implementing Frame Options Frame Options Implementation Considerations Further Information Cookie Security Enhancements Secure Cookies HttpOnly Cookies Cookie Security Implementation Considerations Case Study OnSecure Content Security Policy HTTP Strict Transport Security Frame Options Cookie Security Enhancements Secure Cookies HttpOnly Cookies Implementation Viewing the Security Controls Appendix Implementing the Browser Controls using Apache and Internet Information Services Implementing with Apache Adding New HTTP Headers Altering Existing HTTP Headers Implementing with IIS Adding New HTTP Headers Altering Existing HTTP Headers... 15

3 1 Introduction Web applications are a popular and powerful solution to providing access to information, both internally within an agency and externally to other agencies and the public. Like all software, web applications can have security problems and must be secured appropriately. There is a lot of guidance on securely developing and testing web applications, particularly through resources such as the Open Web Application Security Project 1. However, a lot of web applications are legacy applications with no current support of their source code. This may be due to web applications no longer being supported by the vendor, closed-source code or agencies not having the skillsets required to produce security patches. This can make it difficult or even impossible to implement traditional and effective security controls since they mostly require source code modification. This document provides advice for web developers and IT security professionals on how agencies can protect their existing web applications by implementing low cost and effective security controls, which do not require changes to the application s code. These security controls, when applied to new web applications in development (whether in the application s code or server configuration), form part of the defence-in-depth strategy. The advice is based on DSD s experience in conducting vulnerability assessments of Australian Government systems, including web applications. 2 Leveraging Browser-Based Security Controls Traditionally all web application security controls had to be implemented on the server-side in order to be effective. For example, in the case of input validation client-side JavaScript validation is a possibility; but these security controls are easily bypassed by either disabling JavaScript or altering the request through the use of an intercepting proxy. Developers for PayPal, Mozilla and Microsoft have recently developed three new browser-based security controls: Content Security Policy; HTTP Strict Transport Security; Frame Options. Other advantages of these controls, aside from the increased security are: Ease of implementation: All three security controls are implemented through adding HTTP headers to the web server s response. These headers can be added at the web server, a reverse proxy or within the application. Compatibility: Since they are implemented through HTTP headers, any browser which doesn t support the security control simply ignores the header and operates as normal. The following sections provide an overview of how each security control works, how they are implemented and what should be considered during implementation. While these controls do not stop web application vulnerabilities from being exploited, they reduce or eliminate the consequences of exploitation both for the web application and users. 2.1 Content Security Policy A Content Security Policy (CSP) provides security controls which can mitigate attacks such as cross-site scripting (XSS) and other attacks based on introducing malicious or otherwise undesirable content into a web application. A CSP achieves this by specifying a whitelist of content sources for a web application that a 1 1

4 compatible browser then enforces. A large variety of content can be controlled using a CSP including scripts, images and audio or video. By default, a CSP also implements other mitigations beyond whitelisting content sources. The main additional mitigations are: Inline JavaScript will not execute: this mitigates the most common types of XSS attacks. JavaScript code will not be created from strings: this prevents attackers abusing JavaScript functionality to execute arbitrary JavaScript code. The mitigations that a CSP offers allow an agency to greatly decrease the consequences associated with a web application compromise. This is particularly effective if security patches for the web application are no longer being developed, or will take a long time to deploy. A CSP also offers another benefit - reporting. A CSP can direct the browser to report any breaches of the site s CSP. Using this, an agency can detect attacks against their web applications that may have otherwise gone unnoticed and respond accordingly. CSP Example GovTenders Case Study The mythical Department of Government Tenders has a web application called GovTenders. GovTenders has an XSS vulnerability which allows malicious JavaScript sourced from malicious.example.com to be injected into the page. For example, the adversary inserts <script src= ></script> Without a Content Security Policy the following occurs: 1. A user browses to the compromised page. 2. The web server serves the page to the user. 3. The browser retrieves malicious.example.com/exploit.js and executes it. 4. The malicious JavaScript uses a suitable exploit against the browser and the user s computer is compromised. With a suitable CSP, for example default-src self (this will be explained later), the following would occur: 1. A user browses to the compromised page. 2. The web server serves the page with the addition of the CSP HTTP header to the user. 3. The browser interprets the CSP and determines that content should only be retrieved from 4. The browser ignores the malicious script source and doesn t download it and thus cannot execute it. Although the web application has been successfully exploited, the consequences are minimised as the CSP prevents the user s browser from downloading and executing the malicious JavaScript. This same example could be applied to other content types which CSP can control such as malicious image or audio/video files. 2

5 2.1.1 Implementing a Content Security Policy Enabling CSP for a web application involves configuring the web server to include the CSP HTTP header in all HTTP responses. A CSP policy looks like: HTTP Header Value X-Content-Security-Policy: policy HTTP Header Name In the policy section, the whitelist of content sources is defined, along with violation report directives and changes to the default CSP restrictions such as inline JavaScript CSP Examples The following illustrates example CSP implementations for the GovTenders site: Allow own domain only X-Content-Security-Policy: default-src self The browser will only source content from The default CSP JavaScript security mitigations are enforced as there is no opt-out directive in this policy. Allow subdomains X-Content-Security-Policy: default-src *.govtenders.gov.au The browser will source content from govtenders.gov.au and all subdomains. The default JavaScript security mitigations are enforced. Restrict to self, allow inline JavaScript X-Content-Security-Policy: default-src self unsafe-inline The browser will only source content from and will allow inline JavaScript sourced from the GovTenders domain to execute. Allow everything from anywhere but block third-part scripts X-Content-Security-Policy: default-src *; script-src self The browser will load any content from any domain but will only load JavaScript from Inline JavaScript is not executed. Allow to self and authorised external sources X-Content-Security-Policy: default-src self ; img-src *.cdn.example.com; media-src *.youtube.com; script-src *.jquery.com The browser will load anything from images from cdn.example.com and any subdomains; audio/video from youtube.com and any subdomains; scripts from jquery.com and any subdomains. Force all requests over HTTPS X-Content-Security-Policy: default-src 3

6 The browser will load anything from anywhere, but all requests will use HTTPS. Violation Report Policy X-Content-Security-Policy: default-src self ; report-uri /cspreport The browser will only source content from If anything violates this policy (such as inline JavaScript or an image sourced from any domain other than then the browser submits a CSP violation report to The contents of the report looks like: { csp-report :{ request : GET HTTP/1.1, blockeduri : violated-directive : default-src }} An agency can create a handler for CSP violation reports and action them as appropriate CSP Implementation Considerations Like many security controls, implementing a CSP requires prior planning. This planning will prevent configuration mistakes which may result in disruption to users and the agency s business. Additionally, planning will result in more effective use of the violation report functionality if an agency uses it Developing the CSP Care must be taken to identify all content sources on a web site as well as identifying the use of JavaScript that would be prevented by the default CSP restrictions. If this is not undertaken, users may be affected as they are unable to load required content such as scripts, images or stylesheets. Unless you are very familiar with the site and its development, investigation will be required in order to develop a secure and effective CSP. Web server request logs by themselves are not sufficient as it won t reveal external resources. Some tools and techniques used to plan and develop a CSP are outlined below. CSP bookmarklet A bookmarklet 2 has been created by Mozilla to automatically generate an appropriate CSP for any site. This tool is limited as it only uses the current page to generate the policy. This can lead to non-whitelisted content sources being blocked if they are used on different pages. Spidering Tool A web spider tool provides an automated alternative to manually browsing a site. The tool will automatically follow links on a page and create a list of all pages and sites visited. Depending on the spider s configuration, areas of a site which require user interaction may not be covered. This should be supplemented with manual inspection if required. For example, most intercepting proxies, such as Web Scarab, have spidering capabilities or a standalone tool can be used. Intercepting Proxy An intercepting proxy, such as Web Scarab, can be used to help generate a CSP. By comprehensively browsing the website through an intercepting proxy, a log of all domains the browser requests can be generated. These domains can then be assessed for their inclusion in the CSP. Care should be taken to filter out requests unrelated to the website s content. These unrelated requests, which are common in modern browsers, could include: 2 4

7 malicious web site checks (such as Google s SafeBrowsing); search suggestions; RSS feed updates. The above should be disabled in the browser for the duration of the CSP development or otherwise filtered from the list of CSP allowed domains. Below is an example of using an intercepting proxy for In the request log above, we can see that multiple content sources are used: data.gov.au - the primary content provider data-au.govspace.gov.au - JavaScript s.govspace.gov.au - JavaScript and images govspace.gov.au - an empty response so we will ignore it for this example. Based on the request log data.gov.au s CSP could be: X-Content-Security-Policy: default-src self ; script-src dataau.govspace.gov.au s.govspace.gov.au; img-src s.govspace.gov.au Inline JavaScript If inline JavaScript is used on the site, remediation measures, from most secure to least secure, are: 1. Move inline JavaScript to an externally referenced script file and authorise it using CSP. 5

8 2. Enable CSP inline JavaScript execution only for those pages that require it. 3. Enable CSP inline JavaScript execution across the entire site. CSP was primarily designed to prevent cross-site scripting attacks, therefore enabling inline JavaScript execution compromises the protection it offers Testing the CSP Once the proposed CSP has been developed it is important to test it thoroughly to ensure that all legitimate content sources are authorised. CSP provides a means to help test a deployment in a production environment without disrupting users or the website; Report Only mode. Report Only mode causes browsers to only report violations of the advertised CSP rather than blocking unauthorised content. Report Only mode is enabled by using a different HTTP header: X-Content-Security-Policy-Report-Only: policy Over a test period agencies can review any violation reports to determine whether there are any legitimate content sources which have not been included in the CSP Further Information A Content Security Policy offers effective mitigations against web application attacks based on introducing malicious or otherwise undesirable content into a web application. The CSP examples in do not cover all the possibilities. For further information on developing and deploying CSP refer to: CSP Specification: Mozilla s Guide to CSP: 6

9 HTTP - Get homepage HTTP - Get homepage 2.2 HTTP Strict Transport Security HTTP Strict Transport Security (HSTS) mitigates the threat of eavesdropping and information disclosure. HSTS does this by directing compatible browsers to only use secure connections when communicating with the website. When handling sensitive information it is important that a website uses secure connections for all communications. While this can be challenging, especially for larger or complex sites, common weaknesses of not using secure communications are: HTTPS only being used for submitting a username and password after which the site falls back to HTTP, exposing sensitive information. This can include session IDs which an adversary can use to impersonate a legitimate user 3. Allowing non-secure connections to secure content. A site s default may be to use HTTPS to access secure content but may still allow non-secure connections to this content. For example, a user manually enters or clicks on the link which is not redirected to o This problem can be compounded if the web application rewrites page links according to a previous request. For example, normally all links on GovTenders are but if a request is made using HTTP to access secure content, all links are rewritten to HSTS can help solve these weaknesses without requiring large changes to the web application Example of HSTS in action The following example demonstrates a typical (if abbreviated) transaction sequence of going to the GovTenders website, logging in and providing some sensitive information. Unfortunately the GovTenders site has been poorly developed and allows sensitive data to be passed over unencrypted HTTP requests. User Browser Without HSTS GovTenders User Browser With HSTS GovTenders HTTPS Send homepage HTTPS Send homepage (including HSTS policy) HTTPS - Send login details HTTPS - Send login details HTTPS Authenticated Cookie=XYZ HTTPS Authenticated Cookie=XYZ HTTP Submit credit card details Cookie=XYZ Plaintext HTTP used to transmit sensitive data (credit card and cookie session ID) HTTPS Submit credit card details Cookie=XYZ HSTS forces HTTP to HTTPS 3 The much publicised Firesheep tool exploited Facebook and Twitter s lack of HTTPS for all communications. 7

10 2.2.2 Implementing HTTP Strict Transport Security As with a Content Security Policy, implementing HSTS involves setting an additional HTTPS header to responses. A HSTS directive can only take two different forms: 1. Strict-Transport-Security: max-age=seconds This directs compatible browsers to use HTTPS connections only, for the time specified in seconds. 2. Strict-Transport-Security: max-age=seconds; includesubdomains This does the same, except it extends the HTTPS-only coverage to subdomains HSTS Implementation Considerations There are a number of details which must be considered when implementing an effective HSTS directive. The primary considerations are: HSTS headers must be sent in HTTPS responses only. Compatible browsers will not enforce the HSTS policy sent in plaintext HTTP. The HTTPS response which includes a HSTS header must not have any secure transport errors or warnings. This includes the use of self-signed certificates, domain name mismatches and expired certificates. If a secure transport error or warning occurs, the browser may terminate the connection and not present the user with an option to proceed4. If the site doesn t implement widespread HTTPS use already then there may be an increase in processing overhead due to the implementation of HSTS. The amount of overhead is dependent on a number of factors including website content, session length (this is not login session), caching behaviour and others. Benchmarking the performance of the application with and without HSTS will reveal how much of a processing overhead will be incurred. With these considerations in mind a HSTS header should be set in all HTTPS responses. A compatible browser will update the HSTS expiry for a host each time it receives a valid HSTS directive from that host. The length of time specified in max-age will depend on how long the agency is willing to commit to HTTPS only. A longer expiry time is preferable as the less a user has to connect via plaintext HTTP, the less vulnerable the data exchanged with the web application is. Another factor to consider is agencies do not have to wait until a browser s HSTS entry expires, RFC compliant browsers update their existing expiry time if a different value is specified by the server. However, if the HSTS header is removed, browsers with existing HSTS entries will continue to force HTTPS until the expiry time is reached Further Information Further information on HSTS can be found at: HSTS on Wikipedia (en.wikipedia.org/wiki/http_strict_transport_security): Has a comprehensive overview of HSTS, information on browser support as well as implementation examples for Apache and various web languages. HSTS IETF draft specification: tools.ietf.org/html/draft-ietf-websec-strict-transport-sec This is not part of the specification but is the recommended behaviour for compatible browsers. 8

11 2.3 Frame Options Frame Options prevent the use of legitimate websites as part of a clickjacking attack 5. Frame Options achieves this by defining whether the site s content can be included in a HTML <frame> or <iframe>, which is then enforced by compatible browsers Implementing Frame Options Enabling Frame Options for a website involves configuring the site to include the Frame Options HTTP header on either all HTTP responses or at least on pages which a user should interact with securely, for example login or payment pages, or pages which allow users to perform sensitive actions. A Frame Options directive can be one of three values: 1. X-Frame-Options: DENY - The deny directive prevents the protected content being included in any frame. 2. X-Frame-Options: SAMEORIGIN - The sameorigin directive only allows the protected content to be included in a frame if the framing site is served from the same origin. 3. X-Frame-Options: ALLOW-FROM origin(s) - The allow-from directive allows one or more origins to frame the protected content. Wildcards are not permitted to specify multiple domains Frame Options Implementation Considerations Before deploying Frame Options agencies should determine whether content from the website to be protected is legitimately included in any frames. This can be difficult to determine for sites outside of the agency s control. Checking the HTTP Referer header on requests can reveal where users are being linked from but this will also include legitimate linking rather than just framing. Additionally the Referer header is not always reliable due to the way that the header is handled by browsers and other intermediaries. If legitimate framing is used, it must be determined whether the sameorigin (internal use) or the allowfrom (external use) directive should be used. Additionally, as wildcards are not permitted in an allow-from directive each individual origin must be identified and included Further Information For more information on Frame Options refer to: Frame Options IETF draft specification (tools.ietf.org/html/draft-gondrom-frame-options-01). One of Microsoft s original posts (blogs.msdn.com/b/ieinternals/archive/2010/03/30/combatingclickjacking-with-x-frame-options.aspx). Note: there are some differences between this post and the newer draft specification

12 2.4 Cookie Security Enhancements Cookies are vital to web applications as they provide a means to store information on the client. This information can include site preferences and tracking information, but most importantly cookies are typically used to hold web application session IDs. Due to the stateless nature of HTTP, session IDs are the only practical means of tracking state, such as authentication status. Attacks such as XSS or man-in-the-middle interception exploit the reliance on session IDs in order to impersonate a legitimate user and hijack their session. Therefore protecting cookies containing session IDs is vital to the security of a web application. There are two security controls available, at the cookie level, to help protect cookies; the Secure and HttpOnly options Secure Cookies As identified previously in HTTP Strict Transport Security a web site may use HTTPS on some pages but fail to implement or force its use on others. Because of this, cookies containing session IDs could be sent in the clear allowing the session to be hijacked. To avoid this, the Secure option should be set when issuing cookies containing sensitive data. The Secure option forces compatible browsers to only send the cookie over HTTPS connections, avoiding sending the cookie over plaintext HTTP. To implement Secure cookies, the Secure option is appended to the cookie value when a cookie is set by the server: Set-Cookie: PHPSESSID=1a9vnsk3haqpi29kamrnrul06c5; path=/; Secure HttpOnly Cookies While the Secure option helps ensure that the cookie isn t leaked through insecure communications, it does not protect against the threat of XSS. One potential use of a XSS attack is to steal a user s cookie and send it to the attacker. The attacker can then use the stolen cookie to impersonate the user, bypassing the web application s authentication controls. To protect against this, the HttpOnly option should be set to prevent JavaScript access to the cookie. With the HttpOnly option set, compatible browsers will only retrieve the cookie when it is being sent as part of a HTTP request to the issuing origin. Like the Secure option the HttpOnly option is appended to the cookie value when a cookie is set: Set-Cookie: PHPSESSID=1a9vnsk3haqpi29kamrnrul06c5; path=/; HttpOnly The Secure and HttpOnly options can be set at the same time. Set-Cookie: PHPSESSID=1a9vnsk3haqpi29kamrnrul06c5; path=/; HttpOnly; Secure Cookie Security Implementation Considerations When implementing the Secure and HttpOnly options the site should first be reviewed to determine whether these security enhancements will cause any issues. For example, a key part of a site may not use HTTPS but still expect to receive a cookie. Since the Secure option has been set, the cookie isn t sent to the server over HTTP, which may cause issues. This is indicative of a wider problem of not using HTTPS to protect a web application, rather than an incompatibility with the Secure option. 10

13 3 Case Study OnSecure OnSecure ( is a web application owned and administered by DSD. OnSecure is powered by Drupal, a content management system (CMS). Implementing an existing commercial or open source CMS is a popular choice when developing a web application since a custom solution does not need to be developed and maintained. However a CMS may be vulnerable if security patches are not applied regularly or are no longer released by the developer. Although software developers can be very security conscious, it is almost impossible to develop software that is vulnerability free, particularly as new exploitation techniques are developed. As such, the browser-based security controls provide an additional layer of protection. The author of this document was familiar with OnSecure and its internals and thus had a good idea where to start when it came to configuring and deploying the security controls. However, investigation and testing prior to deployment revealed a number of factors which had to be taken into consideration. 3.1 Content Security Policy OnSecure doesn t source any legitimate content from any origins other than and members.onsecure.gov.au. This means that the CSP should be fairly simple as no additional sources would have to be specified (e.g. img-src, script-src). However, it still needed to be determined whether OnSecure uses inline JavaScript and other JavaScript functionality blocked by CSP s default restrictions. In order to determine if functionality would be affected by not allowing inline JavaScript execution, a report only CSP was deployed: X-Content-Security-Policy-Report-Only: default-src self ; report-uri /dummyreport Rather than create a handler to receive the violation reports on the server, an intercepting proxy was used to view the content of the violation reports as the browser sent them. This allowed a better understanding of whether OnSecure uses inline JavaScript and confirmed that a policy of default-src self would be sufficient and no unsafe-inline option would be needed. However, visiting every page manually is difficult and error prone. To verify that the proposed policy was correct, a simple HTTP POST handler was written in order to log the submitted violation reports. These were then reviewed to determine whether any violations were being reported and under what conditions. Examples of violations reported included: Drupal page template included empty script tags causing an inline JavaScript violation. Various bookmarklets, such as LastPass, triggering violations on inline JavaScript execution, use of data URIs and external media. The violation reports showed that, aside from breaking user bookmarklets, the proposed CSP was correct. Therefore the following CSP was deployed site wide: X-Content-Security-Policy default-src self ; report-uri /cspreport.php The violation report log is reviewed regularly in order to determine if there are any issues or violations that may indicate maliciousness. Enhancements to the report handler will include filtering to reduce the number of false positives and alerting of suspicious reports. 11

14 3.2 HTTP Strict Transport Security OnSecure uses two Apache virtual hosts, one serving the plaintext landing page ( and another serving the SSL-protected member s section ( As sensitive content is only served from members.onsecure.gov.au OnSecure s SSL certificate is only issued for members.onsecure.gov.au, rather than *.onsecure.gov.au. This causes an SSL error due to domain name mismatch if is accessed. Because of this, HSTS could not be enabled server wide as per CSP as the browser would ignore the HSTS directive because of either the SSL error or plaintext HTTP delivery. Therefore the following HSTS directive was only placed in the virtual host configuration which serves Strict-Transport-Security: max-age= If OnSecure s SSL certificate was valid for *.onsecure.gov.au and the entire site was delivered over HTTPS, then a server wide HSTS directive could be used, such as: Strict-Transport-Security: max-age= ; includesubdomains 3.3 Frame Options As with CSP, there was no legitimate use for external sites to include OnSecure content within HTML frames. Therefore, all that was required was to place a suitable directive in all the HTTP responses sent by OnSecure: X-Frame-Options: SAMEORIGIN 3.4 Cookie Security Enhancements Like the majority of web applications, OnSecure uses cookies to hold session IDs used to authenticate a user. It is vital that these cookies are secured to avoid the disclosure of this session ID which can lead to unauthorised access Secure Cookies The implementation of HSTS would help cookies remain secure by ensuring that compatible browsers only communicate over HTTPS with members.onsecure.gov.au, the domain which issues and receives cookies. Unfortunately, not all browsers support HSTS and additional layers of protection are required. Therefore the Secure option was implemented on OnSecure because there is greater browser support for it, and cookies could be protected even if HSTS was unsupported HttpOnly Cookies By implementing a CSP it was known that OnSecure doesn t use JavaScript, especially not to access or manipulate the cookies it issues. As such, the HttpOnly option was implemented to help limit the consequences of a XSS vulnerability being exploited in OnSecure (and if the CSP was ineffective or not supported by the browser) which could lead to session ID theft Implementation Due to the restriction on editing OnSecure source code the addition of the Secure and HttpOnly options to the cookies issued by Drupal was done using Apache, the OnSecure web server. The Apache headers module allows editing of existing headers based on regular expressions. The necessary entry was added to the virtual host configuration to ensure that the resultant cookie directive issued to the user looks like the following truncated example: Set-Cookie: SESS719dja2841=nzkJAh1729Akzj28; HttpOnly; Secure 12

15 3.5 Viewing the Security Controls To view the security controls currently implemented on OnSecure, an intercepting proxy, a browser and extensions (to view HTTP headers) or a tool such as wget can be used. 13

16 Appendix Implementing the Browser Controls using Apache and Internet Information Services The following section describes how browser security controls can be implemented using the two most common web servers; Apache and Internet Information Services (IIS). When implementing the controls, one of the primary considerations, aside from planning the security policies themselves, is determining the level at which to implement the controls. Both Apache and IIS allow controls to be implemented at the following levels at least: Server-wide; Host wide; or Path specific (URLs, directories or files) Implementing with Apache Implementing these security controls in Apache requires the mod_headers module. Adding New HTTP Headers For the OnSecure implementation the CSP, HSTS and Frame Options are implemented through the addition of new headers. Below is an example using the addition of the new CSP HTTP header: Header set X-Content-Security-Policy default-src self ; report-uri /cspreport.php Altering Existing HTTP Headers In the case of the cookie security enhancements, the existing Set-Cookie header (created and added by Drupal) must be altered. The Apache headers module allows editing of existing headers based on regular expressions. The following setting was used to add the security controls: Header edit Set-Cookie ^(.*)$ $1; HttpOnly; Secure ^(.*)$ - Matches and retrieves the entire Set-Cookie value (looking for any characters, any length). $1; HttpOnly; Secure The matched string, in this case the Set-Cookie value, gets placed into $1. Then the two new cookie options are appended, using semicolons as separators. For further information on configuring Apache see: Apache Headers module: httpd.apache.org/docs/current/mod/mod_headers.html. Apache configuration sections: httpd.apache.org/docs/current/sections.html Implementing with IIS Although IIS supports the addition of custom HTTP response headers using the HTTP Response Headers feature, it does not support conditional or more advanced processing out-of-the-box. However, an IIS extension, URL Rewrite, offers this functionality. For consistency the examples below were all implemented using URL Rewrite. This implementation used IIS 7.5. Adding New HTTP Headers Below is an example of adding a new header, the CSP, to the HTTP response: 14

17 <rule name="content Security Policy"> <match servervariable="response_x_content_security_policy" pattern="^$" /> <action type="rewrite" value="default-src 'self'; report-uri /cspreport.php" /> </rule> Although it is adding a new header URL Rewrite still requires the use of a dummy matching rule. Altering Existing HTTP Headers The conditions feature is used to alter existing HTTP headers. The following is an example of the rule required to alter existing Set-Cookie header to include the cookie security enhancements: <rule name="cookie Security Enhancements" precondition="set-cookie Exists"> <match servervariable="response_set_cookie" pattern="^(.*)$" /> <conditions> <add input= {RESPONSE_SET_COOKIE} pattern=. /> </conditions> <action type="rewrite" value="{r:0}; HttpOnly; Secure" /> </rule> The conditions element requires that a Set-Cookie header be present in the response before the new security flags are appended to the Set-Cookie value. For further information on using IIS and URL Rewrite see: URL Rewrite: o o o o IIS 7 configuration files: 15

Recent Advances in Web Application Security

Recent Advances in Web Application Security Recent Advances in Web Application Security Author: Neelay S Shah Principal Security Consultant Foundstone Professional Services Table of Contents Introduction 3 Content Security Policy 3 Best Practices

More information

Web Application Security

Web Application Security Web Application Security The OWASP Foundation Securing the application Input validation Authorization Session mgmt Config mgmt Authenticatio n Error handling Web server App server DB server Secure storage

More information

Security starts in the head(er)

Security starts in the head(er) Security starts in the head(er) JavaOne 2014 Dominik Schadow bridgingit Policies are independent of framework and language response.addheader(! "Policy name",! "Policy value"! ); User agent must understand

More information

Recent Web Security Technology. Lieven Desmet iminds-distrinet-ku Leuven 3th February 2015 B-CCENTRE closing workshop Lieven.Desmet@cs.kuleuven.

Recent Web Security Technology. Lieven Desmet iminds-distrinet-ku Leuven 3th February 2015 B-CCENTRE closing workshop Lieven.Desmet@cs.kuleuven. Recent Web Security Technology Lieven Desmet iminds-distrinet-ku Leuven 3th February 2015 B-CCENTRE closing workshop Lieven.Desmet@cs.kuleuven.be About myself: Lieven Desmet Research manager at KU Leuven

More information

Real World Java Web Security

Real World Java Web Security Real World Java Web Security Java User Group Karlsruhe Dominik Schadow bridgingit Who thinks about architecture while coding? architecture before coding? Who thinks about security while coding? security

More information

A Server and Browser-Transparent CSRF Defense for Web 2.0 Applications. Slides by Connor Schnaith

A Server and Browser-Transparent CSRF Defense for Web 2.0 Applications. Slides by Connor Schnaith A Server and Browser-Transparent CSRF Defense for Web 2.0 Applications Slides by Connor Schnaith Cross-Site Request Forgery One-click attack, session riding Recorded since 2001 Fourth out of top 25 most

More information

Sichere Webanwendungen mit Java

Sichere Webanwendungen mit Java Sichere Webanwendungen mit Java Karlsruher IT- Sicherheitsinitiative 16.07.2015 Dominik Schadow bridgingit Patch fast Unsafe platform unsafe web application Now lets have a look at the developers OWASP

More information

Hack Proof Your Webapps

Hack Proof Your Webapps Hack Proof Your Webapps About ERM About the speaker Web Application Security Expert Enterprise Risk Management, Inc. Background Web Development and System Administration Florida International University

More information

AppSec USA 2014 Denver, Colorado Security Header Injection Module (SHIM)

AppSec USA 2014 Denver, Colorado Security Header Injection Module (SHIM) AppSec USA 2014 Denver, Colorado Security Header Injection Module (SHIM) Inspired By: The OWASP Secure Headers Project Introduction Eric Johnson (@emjohn20) Cypress Data Defense Security Consultant SANS

More information

A Study of What Really Breaks SSL HITB Amsterdam 2011

A Study of What Really Breaks SSL HITB Amsterdam 2011 A Study of What Really Breaks SSL HITB Amsterdam 2011 v1.0 Ivan Ristic Michael Small 20 May 2011 Agenda 1. State of SSL 2. Quick intro to SSL Labs 3. SSL Configuration Surveys 4. Survey of Actual SSL Usage

More information

Check list for web developers

Check list for web developers Check list for web developers Requirement Yes No Remarks 1. Input Validation 1.1) Have you done input validation for all the user inputs using white listing and/or sanitization? 1.2) Does the input validation

More information

What is Web Security? Motivation

What is Web Security? Motivation brucker@inf.ethz.ch http://www.brucker.ch/ Information Security ETH Zürich Zürich, Switzerland Information Security Fundamentals March 23, 2004 The End Users View The Server Providers View What is Web

More information

Relax Everybody: HTML5 Is Securer Than You Think

Relax Everybody: HTML5 Is Securer Than You Think Relax Everybody: HTML5 Is Securer Than You Think Martin Johns (@datenkeller) SAP AG Session ID: ADS-W08 Session Classification: Advanced Motivation For some reason, there is a preconception that HTML5

More information

Criteria for web application security check. Version 2015.1

Criteria for web application security check. Version 2015.1 Criteria for web application security check Version 2015.1 i Content Introduction... iii ISC- P- 001 ISC- P- 001.1 ISC- P- 001.2 ISC- P- 001.3 ISC- P- 001.4 ISC- P- 001.5 ISC- P- 001.6 ISC- P- 001.7 ISC-

More information

SESSION IDENTIFIER ARE FOR NOW, PASSWORDS ARE FOREVER

SESSION IDENTIFIER ARE FOR NOW, PASSWORDS ARE FOREVER SESSION IDENTIFIER ARE FOR NOW, PASSWORDS ARE FOREVER XSS-BASED ABUSE OF BROWSER PASSWORD MANAGERS Ben Stock, Martin Johns, Sebastian Lekies Browser choices Full disclosure: Ben was an intern with Microsoft

More information

Malicious Email Mitigation Strategy Guide

Malicious Email Mitigation Strategy Guide CYBER SECURITY OPERATIONS CENTRE Malicious Email Mitigation Strategy Guide Introduction (UPDATED) SEPTEMBER 2012 1. Socially engineered emails containing malicious attachments and embedded links are commonly

More information

An Insight into Cookie Security

An Insight into Cookie Security An Insight into Cookie Security Today most websites and web based applications use cookies. Cookies are primarily used by the web server to track an authenticated user or other user specific details. This

More information

Web Application Report

Web Application Report Web Application Report This report includes important security information about your Web Application. Security Report This report was created by IBM Rational AppScan 8.5.0.1 11/14/2012 8:52:13 AM 11/14/2012

More information

Secure development and the SDLC. Presented By Jerry Hoff @jerryhoff

Secure development and the SDLC. Presented By Jerry Hoff @jerryhoff Secure development and the SDLC Presented By Jerry Hoff @jerryhoff Agenda Part 1: The Big Picture Part 2: Web Attacks Part 3: Secure Development Part 4: Organizational Defense Part 1: The Big Picture Non

More information

EVALUATING COMMERCIAL WEB APPLICATION SECURITY. By Aaron Parke

EVALUATING COMMERCIAL WEB APPLICATION SECURITY. By Aaron Parke EVALUATING COMMERCIAL WEB APPLICATION SECURITY By Aaron Parke Outline Project background What and why? Targeted sites Testing process Burp s findings Technical talk My findings and thoughts Questions Project

More information

Recommended Practice Case Study: Cross-Site Scripting. February 2007

Recommended Practice Case Study: Cross-Site Scripting. February 2007 Recommended Practice Case Study: Cross-Site Scripting February 2007 iii ACKNOWLEDGEMENT This document was developed for the U.S. Department of Homeland Security to provide guidance for control system cyber

More information

BASELINE SECURITY TEST PLAN FOR EDUCATIONAL WEB AND MOBILE APPLICATIONS

BASELINE SECURITY TEST PLAN FOR EDUCATIONAL WEB AND MOBILE APPLICATIONS BASELINE SECURITY TEST PLAN FOR EDUCATIONAL WEB AND MOBILE APPLICATIONS Published by Tony Porterfield Feb 1, 2015. Overview The intent of this test plan is to evaluate a baseline set of data security practices

More information

Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security

Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security Presented 2009-05-29 by David Strauss Thinking Securely Security is a process, not

More information

1. Introduction. 2. Web Application. 3. Components. 4. Common Vulnerabilities. 5. Improving security in Web applications

1. Introduction. 2. Web Application. 3. Components. 4. Common Vulnerabilities. 5. Improving security in Web applications 1. Introduction 2. Web Application 3. Components 4. Common Vulnerabilities 5. Improving security in Web applications 2 What does World Wide Web security mean? Webmasters=> confidence that their site won

More information

APPLICATION SECURITY AND ITS IMPORTANCE

APPLICATION SECURITY AND ITS IMPORTANCE Table of Contents APPLICATION SECURITY AND ITS IMPORTANCE 1 ISSUES AND FIXES: 2 ISSUE: XSS VULNERABILITIES 2 ISSUE: CSRF VULNERABILITY 2 ISSUE: CROSS FRAME SCRIPTING (XSF)/CLICK JACKING 2 ISSUE: WEAK CACHE

More information

Evading Web XSS Filters through Word (Microsoft Office and Open Office) in Enterprise Web Applications

Evading Web XSS Filters through Word (Microsoft Office and Open Office) in Enterprise Web Applications Evading Web XSS Filters through Word (Microsoft Office and Open Office) in Enterprise Web Applications Date: 11 March 2009 Aditya K Sood, http://www.secniche.com http://www.secniche.org adi_ks [at] secniche.org

More information

Protecting Your Organisation from Targeted Cyber Intrusion

Protecting Your Organisation from Targeted Cyber Intrusion Protecting Your Organisation from Targeted Cyber Intrusion How the 35 mitigations against targeted cyber intrusion published by Defence Signals Directorate can be implemented on the Microsoft technology

More information

White Paper Secure Reverse Proxy Server and Web Application Firewall

White Paper Secure Reverse Proxy Server and Web Application Firewall White Paper Secure Reverse Proxy Server and Web Application Firewall 2 Contents 3 3 4 4 8 Losing control Online accessibility means vulnerability Regain control with a central access point Strategic security

More information

WHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats

WHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats WHITE PAPER FortiWeb and the OWASP Top 10 PAGE 2 Introduction The Open Web Application Security project (OWASP) Top Ten provides a powerful awareness document for web application security. The OWASP Top

More information

DNS Pinning and Web Proxies

DNS Pinning and Web Proxies DNS Pinning and Web Proxies An NGSSoftware Insight Security Research (NISR) Publication 2007 Next Generation Security Software Ltd Abstract DNS-based attacks can be used to perform a partial breach of

More information

Implementation of Web Application Firewall

Implementation of Web Application Firewall Implementation of Web Application Firewall OuTian 1 Introduction Abstract Web 層 應 用 程 式 之 攻 擊 日 趨 嚴 重, 而 國 內 多 數 企 業 仍 不 知 該 如 何 以 資 安 設 備 阻 擋, 仍 在 採 購 傳 統 的 Firewall/IPS,

More information

Web applications. Web security: web basics. HTTP requests. URLs. GET request. Myrto Arapinis School of Informatics University of Edinburgh

Web applications. Web security: web basics. HTTP requests. URLs. GET request. Myrto Arapinis School of Informatics University of Edinburgh Web applications Web security: web basics Myrto Arapinis School of Informatics University of Edinburgh HTTP March 19, 2015 Client Server Database (HTML, JavaScript) (PHP) (SQL) 1 / 24 2 / 24 URLs HTTP

More information

External Vulnerability Assessment. -Technical Summary- ABC ORGANIZATION

External Vulnerability Assessment. -Technical Summary- ABC ORGANIZATION External Vulnerability Assessment -Technical Summary- Prepared for: ABC ORGANIZATI On March 9, 2008 Prepared by: AOS Security Solutions 1 of 13 Table of Contents Executive Summary... 3 Discovered Security

More information

Finding and Preventing Cross- Site Request Forgery. Tom Gallagher Security Test Lead, Microsoft

Finding and Preventing Cross- Site Request Forgery. Tom Gallagher Security Test Lead, Microsoft Finding and Preventing Cross- Site Request Forgery Tom Gallagher Security Test Lead, Microsoft Agenda Quick reminder of how HTML forms work How cross-site request forgery (CSRF) attack works Obstacles

More information

How to break in. Tecniche avanzate di pen testing in ambito Web Application, Internal Network and Social Engineering

How to break in. Tecniche avanzate di pen testing in ambito Web Application, Internal Network and Social Engineering How to break in Tecniche avanzate di pen testing in ambito Web Application, Internal Network and Social Engineering Time Agenda Agenda Item 9:30 10:00 Introduction 10:00 10:45 Web Application Penetration

More information

CS 558 Internet Systems and Technologies

CS 558 Internet Systems and Technologies CS 558 Internet Systems and Technologies Dimitris Deyannis deyannis@csd.uoc.gr 881 Heat seeking Honeypots: Design and Experience Abstract Compromised Web servers are used to perform many malicious activities.

More information

Gateway Apps - Security Summary SECURITY SUMMARY

Gateway Apps - Security Summary SECURITY SUMMARY Gateway Apps - Security Summary SECURITY SUMMARY 27/02/2015 Document Status Title Harmony Security summary Author(s) Yabing Li Version V1.0 Status draft Change Record Date Author Version Change reference

More information

(WAPT) Web Application Penetration Testing

(WAPT) Web Application Penetration Testing (WAPT) Web Application Penetration Testing Module 0: Introduction 1. Introduction to the course. 2. How to get most out of the course 3. Resources you will need for the course 4. What is WAPT? Module 1:

More information

Specific recommendations

Specific recommendations Background OpenSSL is an open source project which provides a Secure Socket Layer (SSL) V2/V3 and Transport Layer Security (TLS) V1 implementation along with a general purpose cryptographic library. It

More information

Internet Banking System Web Application Penetration Test Report

Internet Banking System Web Application Penetration Test Report Internet Banking System Web Application Penetration Test Report Kiev - 2014 1. Executive Summary This report represents the results of the Bank (hereinafter the Client) Internet Banking Web Application

More information

Where every interaction matters.

Where every interaction matters. Where every interaction matters. Peer 1 Vigilant Web Application Firewall Powered by Alert Logic The Open Web Application Security Project (OWASP) Top Ten Web Security Risks and Countermeasures White Paper

More information

EXECUTIVE OFFICE OF THE PRESIDENT OFFICE OF MANAGEMENT AND BUDGET WASHINGTON, D.C. 20503. June 8, 2015

EXECUTIVE OFFICE OF THE PRESIDENT OFFICE OF MANAGEMENT AND BUDGET WASHINGTON, D.C. 20503. June 8, 2015 EXECUTIVE OFFICE OF THE PRESIDENT OFFICE OF MANAGEMENT AND BUDGET WASHINGTON, D.C. 20503 June 8, 2015 M-15-13 MEMORANDUM FOR THE HEADS OF EXECUTIVE DEP FROM: SUBJECT: Tony Scott Federal Chief Information

More information

Christchurch Polytechnic Institute of Technology Information Systems Acquisition, Development and Maintenance Security Standard

Christchurch Polytechnic Institute of Technology Information Systems Acquisition, Development and Maintenance Security Standard Christchurch Polytechnic Institute of Technology Information Systems Acquisition, Development and Maintenance Security Standard Corporate Policies & Procedures Section 1: General Administration Document

More information

ABC LTD EXTERNAL WEBSITE AND INFRASTRUCTURE IT HEALTH CHECK (ITHC) / PENETRATION TEST

ABC LTD EXTERNAL WEBSITE AND INFRASTRUCTURE IT HEALTH CHECK (ITHC) / PENETRATION TEST ABC LTD EXTERNAL WEBSITE AND INFRASTRUCTURE IT HEALTH CHECK (ITHC) / PENETRATION TEST Performed Between Testing start date and end date By SSL247 Limited SSL247 Limited 63, Lisson Street Marylebone London

More information

HTTPS Inspection with Cisco CWS

HTTPS Inspection with Cisco CWS White Paper HTTPS Inspection with Cisco CWS What is HTTPS? Hyper Text Transfer Protocol Secure (HTTPS) is a secure version of the Hyper Text Transfer Protocol (HTTP). It is a combination of HTTP and a

More information

The Top Web Application Attacks: Are you vulnerable?

The Top Web Application Attacks: Are you vulnerable? QM07 The Top Web Application Attacks: Are you vulnerable? John Burroughs, CISSP Sr Security Architect, Watchfire Solutions jburroughs@uk.ibm.com Agenda Current State of Web Application Security Understanding

More information

Web application security

Web application security Web application security Sebastian Lopienski CERN Computer Security Team openlab and summer lectures 2010 (non-web question) Is this OK? int set_non_root_uid(int uid) { // making sure that uid is not 0

More information

Guidelines for Web applications protection with dedicated Web Application Firewall

Guidelines for Web applications protection with dedicated Web Application Firewall Guidelines for Web applications protection with dedicated Web Application Firewall Prepared by: dr inŝ. Mariusz Stawowski, CISSP Bartosz Kryński, Imperva Certified Security Engineer INTRODUCTION Security

More information

Semantic based Web Application Firewall (SWAF V 1.6) Operations and User Manual. Document Version 1.0

Semantic based Web Application Firewall (SWAF V 1.6) Operations and User Manual. Document Version 1.0 Semantic based Web Application Firewall (SWAF V 1.6) Operations and User Manual Document Version 1.0 Table of Contents 1 SWAF... 4 1.1 SWAF Features... 4 2 Operations and User Manual... 7 2.1 SWAF Administrator

More information

Java-Web-Security Anti-Patterns

Java-Web-Security Anti-Patterns Java-Web-Security Anti-Patterns Entwicklertag 20.05.2015 Dominik Schadow bridgingit Failed with only the best intentions Design Implement Maintain Design Ignoring threat modeling defense in depth Threat

More information

Web Application Firewall

Web Application Firewall Web Application Firewall Getting Started Guide August 3, 2015 Copyright 2014-2015 by Qualys, Inc. All Rights Reserved. Qualys and the Qualys logo are registered trademarks of Qualys, Inc. All other trademarks

More information

Cross Site Scripting Prevention

Cross Site Scripting Prevention Project Report CS 649 : Network Security Cross Site Scripting Prevention Under Guidance of Prof. Bernard Menezes Submitted By Neelamadhav (09305045) Raju Chinthala (09305056) Kiran Akipogu (09305074) Vijaya

More information

Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified

Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified Standard: Data Security Standard (DSS) Requirement: 6.6 Date: February 2008 Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified Release date: 2008-04-15 General PCI

More information

Application Reviews and Web Application Firewalls Clarified. Information Supplement: PCI Data Security Standard (PCI DSS) Requirement:

Application Reviews and Web Application Firewalls Clarified. Information Supplement: PCI Data Security Standard (PCI DSS) Requirement: Standard: Version: Date: Requirement: Author: PCI Data Security Standard (PCI DSS) 1.2 October 2008 6.6 PCI Security Standards Council Information Supplement: Application Reviews and Web Application Firewalls

More information

Acunetix Website Audit. 5 November, 2014. Developer Report. Generated by Acunetix WVS Reporter (v8.0 Build 20120808)

Acunetix Website Audit. 5 November, 2014. Developer Report. Generated by Acunetix WVS Reporter (v8.0 Build 20120808) Acunetix Website Audit 5 November, 2014 Developer Report Generated by Acunetix WVS Reporter (v8.0 Build 20120808) Scan of http://filesbi.go.id:80/ Scan details Scan information Starttime 05/11/2014 14:44:06

More information

WHITE PAPER FORTIWEB WEB APPLICATION FIREWALL. Ensuring Compliance for PCI DSS 6.5 and 6.6

WHITE PAPER FORTIWEB WEB APPLICATION FIREWALL. Ensuring Compliance for PCI DSS 6.5 and 6.6 WHITE PAPER FORTIWEB WEB APPLICATION FIREWALL Ensuring Compliance for PCI DSS 6.5 and 6.6 CONTENTS 04 04 06 08 11 12 13 Overview Payment Card Industry Data Security Standard PCI Compliance for Web Applications

More information

Application Layer Encryption: Protecting against Application Logic and Session Theft Attacks. Whitepaper

Application Layer Encryption: Protecting against Application Logic and Session Theft Attacks. Whitepaper Application Layer Encryption: Protecting against Application Logic and Session Theft Attacks Whitepaper The security industry has extensively focused on protecting against malicious injection attacks like

More information

Session Management in Web Applications

Session Management in Web Applications Session Management in Web Applications Author: EUROSEC GmbH Chiffriertechnik & Sicherheit Tel: 06173 / 60850, www.eurosec.com EUROSEC GmbH Chiffriertechnik & Sicherheit, 2005 What is Web-based Session

More information

Phishing by data URI

Phishing by data URI Phishing by data URI Henning Klevjer henning@klevjers.com October 22, 2012 1 Abstract Historically, phishing web pages have been hosted by web servers that are either compromised or owned by the attacker.

More information

Thomas Röthlisberger IT Security Analyst thomas.roethlisberger@csnc.ch

Thomas Röthlisberger IT Security Analyst thomas.roethlisberger@csnc.ch Thomas Röthlisberger IT Security Analyst thomas.roethlisberger@csnc.ch Compass Security AG Werkstrasse 20 Postfach 2038 CH-8645 Jona Tel +41 55 214 41 60 Fax +41 55 214 41 61 team@csnc.ch www.csnc.ch What

More information

Cryptography for Software and Web Developers

Cryptography for Software and Web Developers Cryptography for Software and Web Developers Part 1: Web and Crypto Hanno Böck 2014-05-28 1 / 14 HTTP and HTTPS SSL Stripping Cookies Mixed content HTTPS content, HTTP images Many webpages use some kind

More information

Hardening Joomla 1. HARDENING PHP. 1.1 Installing Suhosin. 1.2 Disable Remote Includes. 1.3 Disable Unneeded Functions & Classes

Hardening Joomla 1. HARDENING PHP. 1.1 Installing Suhosin. 1.2 Disable Remote Includes. 1.3 Disable Unneeded Functions & Classes 1. HARDENING PHP Hardening Joomla 1.1 Installing Suhosin Suhosin is a PHP Hardening patch which aims to protect the PHP engine and runtime environment from common exploits, such as buffer overflows in

More information

Protection, Usability and Improvements in Reflected XSS Filters

Protection, Usability and Improvements in Reflected XSS Filters Protection, Usability and Improvements in Reflected XSS Filters Riccardo Pelizzi System Security Lab Department of Computer Science Stony Brook University May 2, 2012 1 / 19 Riccardo Pelizzi Improvements

More information

Application security testing: Protecting your application and data

Application security testing: Protecting your application and data E-Book Application security testing: Protecting your application and data Application security testing is critical in ensuring your data and application is safe from security attack. This ebook offers

More information

Web Same-Origin-Policy Exploration Lab

Web Same-Origin-Policy Exploration Lab Laboratory for Computer Security Education 1 Web Same-Origin-Policy Exploration Lab (Web Application: Collabtive) Copyright c 2006-2011 Wenliang Du, Syracuse University. The development of this document

More information

Defending your Web Applications from Attack: Presenter: Damira Pon, UAlbany. NYS Forum Web & Accessibility Workgroup Talk. NYS Forum Training Room

Defending your Web Applications from Attack: Presenter: Damira Pon, UAlbany. NYS Forum Web & Accessibility Workgroup Talk. NYS Forum Training Room Defending your Web Applications from Attack: Current Web-Based Threats, Resources & Tools Presenter: Damira Pon, UAlbany NYS Forum Talk NYS Forum Training Room 24 Aviation Rd. Albany, NY 9:00am 12:00pm

More information

Adobe Systems Incorporated

Adobe Systems Incorporated Adobe Connect 9.2 Page 1 of 8 Adobe Systems Incorporated Adobe Connect 9.2 Hosted Solution June 20 th 2014 Adobe Connect 9.2 Page 2 of 8 Table of Contents Engagement Overview... 3 About Connect 9.2...

More information

Bug Report. Date: March 19, 2011 Reporter: Chris Jarabek (cjjarabe@ucalgary.ca)

Bug Report. Date: March 19, 2011 Reporter: Chris Jarabek (cjjarabe@ucalgary.ca) Bug Report Date: March 19, 2011 Reporter: Chris Jarabek (cjjarabe@ucalgary.ca) Software: Kimai Version: 0.9.1.1205 Website: http://www.kimai.org Description: Kimai is a web based time-tracking application.

More information

Web Application Security

Web Application Security Web Application Security John Zaharopoulos ITS - Security 10/9/2012 1 Web App Security Trends Web 2.0 Dynamic Webpages Growth of Ajax / Client side Javascript Hardening of OSes Secure by default Auto-patching

More information

Out of the Fire - Adding Layers of Protection When Deploying Oracle EBS to the Internet

Out of the Fire - Adding Layers of Protection When Deploying Oracle EBS to the Internet Out of the Fire - Adding Layers of Protection When Deploying Oracle EBS to the Internet March 8, 2012 Stephen Kost Chief Technology Officer Integrigy Corporation Phil Reimann Director of Business Development

More information

Lecture 11 Web Application Security (part 1)

Lecture 11 Web Application Security (part 1) Lecture 11 Web Application Security (part 1) Computer and Network Security 4th of January 2016 Computer Science and Engineering Department CSE Dep, ACS, UPB Lecture 11, Web Application Security (part 1)

More information

OWASP TOP 10 ILIA ALSHANETSKY @ILIAA HTTPS://JOIND.IN/15741

OWASP TOP 10 ILIA ALSHANETSKY @ILIAA HTTPS://JOIND.IN/15741 OWASP TOP 10 ILIA ALSHANETSKY @ILIAA HTTPS://JOIND.IN/15741 ME, MYSELF & I PHP Core Developer Author of Guide to PHP Security Security Aficionado THE CONUNDRUM USABILITY SECURITY YOU CAN HAVE ONE ;-) OPEN

More information

Web Application Security. Vulnerabilities, Weakness and Countermeasures. Massimo Cotelli CISSP. Secure

Web Application Security. Vulnerabilities, Weakness and Countermeasures. Massimo Cotelli CISSP. Secure Vulnerabilities, Weakness and Countermeasures Massimo Cotelli CISSP Secure : Goal of This Talk Security awareness purpose Know the Web Application vulnerabilities Understand the impacts and consequences

More information

Penetration Test Report

Penetration Test Report Penetration Test Report Acme Test Company ACMEIT System 26 th November 2010 Executive Summary Info-Assure Ltd was engaged by Acme Test Company to perform an IT Health Check (ITHC) on the ACMEIT System

More information

State of The Art: Automated Black Box Web Application Vulnerability Testing. Jason Bau, Elie Bursztein, Divij Gupta, John Mitchell

State of The Art: Automated Black Box Web Application Vulnerability Testing. Jason Bau, Elie Bursztein, Divij Gupta, John Mitchell Stanford Computer Security Lab State of The Art: Automated Black Box Web Application Vulnerability Testing, Elie Bursztein, Divij Gupta, John Mitchell Background Web Application Vulnerability Protection

More information

Vulnerability Scans Remote Support 15.1

Vulnerability Scans Remote Support 15.1 Vulnerability Scans Remote Support 15.1 215 Bomgar Corporation. All rights reserved worldwide. BOMGAR and the BOMGAR logo are trademarks of Bomgar Corporation; other trademarks shown are the property of

More information

3. Broken Account and Session Management. 4. Cross-Site Scripting (XSS) Flaws. Web browsers execute code sent from websites. Account Management

3. Broken Account and Session Management. 4. Cross-Site Scripting (XSS) Flaws. Web browsers execute code sent from websites. Account Management What is an? s Ten Most Critical Web Application Security Vulnerabilities Anthony LAI, CISSP, CISA Chapter Leader (Hong Kong) anthonylai@owasp.org Open Web Application Security Project http://www.owasp.org

More information

Certified Secure Web Application Security Test Checklist

Certified Secure Web Application Security Test Checklist www.certifiedsecure.com info@certifiedsecure.com Tel.: +31 (0)70 310 13 40 Loire 128-A 2491 AJ The Hague The Netherlands Certified Secure Checklist About Certified Secure exists to encourage and fulfill

More information

Cross-Site Scripting

Cross-Site Scripting Cross-Site Scripting (XSS) Computer and Network Security Seminar Fabrice Bodmer (fabrice.bodmer@unifr.ch) UNIFR - Winter Semester 2006-2007 XSS: Table of contents What is Cross-Site Scripting (XSS)? Some

More information

Force.com Sites Implementation Guide

Force.com Sites Implementation Guide Force.com Sites Implementation Guide Salesforce, Winter 16 @salesforcedocs Last updated: October 16, 2015 Copyright 2000 2015 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark

More information

Department of Computing Imperial College London. BrowserAudit. A web application that tests the security of browser implementations

Department of Computing Imperial College London. BrowserAudit. A web application that tests the security of browser implementations Department of Computing Imperial College London BrowserAudit A web application that tests the security of browser implementations Charlie Hothersall-Thomas Supervisor: Dr. Sergio Maffeis June 2014 Submitted

More information

Last update: February 23, 2004

Last update: February 23, 2004 Last update: February 23, 2004 Web Security Glossary The Web Security Glossary is an alphabetical index of terms and terminology relating to web application security. The purpose of the Glossary is to

More information

Web Application Guidelines

Web Application Guidelines Web Application Guidelines Web applications have become one of the most important topics in the security field. This is for several reasons: It can be simple for anyone to create working code without security

More information

elearning for Secure Application Development

elearning for Secure Application Development elearning for Secure Application Development Curriculum Application Security Awareness Series 1-2 Secure Software Development Series 2-8 Secure Architectures and Threat Modeling Series 9 Application Security

More information

Additional Security Considerations and Controls for Virtual Private Networks

Additional Security Considerations and Controls for Virtual Private Networks CYBER SECURITY OPERATIONS CENTRE APRIL 2013 (U) LEGAL NOTICE: THIS PUBLICATION HAS BEEN PRODUCED BY THE DEFENCE SIGNALS DIRECTORATE (DSD), ALSO KNOWN AS THE AUSTRALIAN SIGNALS DIRECTORATE (ASD). ALL REFERENCES

More information

Certified Secure Web Application Secure Development Checklist

Certified Secure Web Application Secure Development Checklist www.certifiedsecure.com info@certifiedsecure.com Tel.: +31 (0)70 310 13 40 Loire 128-A 2491 AJ The Hague The Netherlands About Certified Secure Checklist Certified Secure exists to encourage and fulfill

More information

Web Application Firewall on SonicWALL SRA

Web Application Firewall on SonicWALL SRA Web Application Firewall on SonicWALL SRA Document Scope This document describes how to configure and use the Web Application Firewall feature in SonicWALL SRA 6.0. This document contains the following

More information

Testing Web Applications for SQL Injection Sam Shober SamShober@Hotmail.com

Testing Web Applications for SQL Injection Sam Shober SamShober@Hotmail.com Testing Web Applications for SQL Injection Sam Shober SamShober@Hotmail.com Abstract: This paper discusses the SQL injection vulnerability, its impact on web applications, methods for pre-deployment and

More information

Client Side Filter Enhancement using Web Proxy

Client Side Filter Enhancement using Web Proxy Client Side Filter Enhancement using Web Proxy Santosh Kumar Singh 1, Rahul Shrivastava 2 1 M Tech Scholar, Computer Technology (CSE) RCET, Bhilai (CG) India, 2 Assistant Professor, CSE Department, RCET

More information

Locking down a Hitachi ID Suite server

Locking down a Hitachi ID Suite server Locking down a Hitachi ID Suite server 2016 Hitachi ID Systems, Inc. All rights reserved. Organizations deploying Hitachi ID Identity and Access Management Suite need to understand how to secure its runtime

More information

Client vs. Server Implementations of Mitigating XSS Security Threats on Web Applications

Client vs. Server Implementations of Mitigating XSS Security Threats on Web Applications Journal of Basic and Applied Engineering Research pp. 50-54 Krishi Sanskriti Publications http://www.krishisanskriti.org/jbaer.html Client vs. Server Implementations of Mitigating XSS Security Threats

More information

Installation and configuration guide

Installation and configuration guide Installation and Configuration Guide Installation and configuration guide Adding X-Username support to Forward and Reverse Proxy TMG Servers Published: December 2010 Applies to: Winfrasoft X-Username for

More information

FileCloud Security FAQ

FileCloud Security FAQ is currently used by many large organizations including banks, health care organizations, educational institutions and government agencies. Thousands of organizations rely on File- Cloud for their file

More information

Sitefinity Security and Best Practices

Sitefinity Security and Best Practices Sitefinity Security and Best Practices Table of Contents Overview The Ten Most Critical Web Application Security Risks Injection Cross-Site-Scripting (XSS) Broken Authentication and Session Management

More information

Web Application Attacks and Countermeasures: Case Studies from Financial Systems

Web Application Attacks and Countermeasures: Case Studies from Financial Systems Web Application Attacks and Countermeasures: Case Studies from Financial Systems Dr. Michael Liu, CISSP, Senior Application Security Consultant, HSBC Inc Overview Information Security Briefing Web Applications

More information

Application Security Testing. Generic Test Strategy

Application Security Testing. Generic Test Strategy Application Security Testing Generic Test Strategy Page 2 of 8 Contents 1 Introduction 3 1.1 Purpose: 3 1.2 Application Security Testing: 3 2 Audience 3 3 Test Strategy guidelines 3 3.1 Authentication

More information

STOPPING LAYER 7 ATTACKS with F5 ASM. Sven Müller Security Solution Architect

STOPPING LAYER 7 ATTACKS with F5 ASM. Sven Müller Security Solution Architect STOPPING LAYER 7 ATTACKS with F5 ASM Sven Müller Security Solution Architect Agenda Who is targeted How do Layer 7 attacks look like How to protect against Layer 7 attacks Building a security policy Layer

More information

Secure Web Development Teaching Modules 1. Threat Assessment

Secure Web Development Teaching Modules 1. Threat Assessment Secure Web Development Teaching Modules 1 Threat Assessment Contents 1 Concepts... 1 1.1 Software Assurance Maturity Model... 1 1.2 Security practices for construction... 3 1.3 Web application security

More information

Attack and Penetration Testing 101

Attack and Penetration Testing 101 Attack and Penetration Testing 101 Presented by Paul Petefish PaulPetefish@Solutionary.com July 15, 2009 Copyright 2000-2009, Solutionary, Inc. All rights reserved. Version 2.2 Agenda Penetration Testing

More information

Information Technology Policy

Information Technology Policy Information Technology Policy Enterprise Web Application Firewall ITP Number ITP-SEC004 Category Recommended Policy Contact RA-ITCentral@pa.gov Effective Date January 15, 2010 Supersedes Scheduled Review

More information