Solution Requirements and Guidelines The following is a list of requirements and guidelines that will be used to govern the design and implementation of the new OSS SS Anti-‐CSRF solution. Although the implementation for this project will be specific to J2EE web application architectures, these requirements and guidelines have been generalized to the extent possible. The intention is to provide future Anti-‐CSRF solution developers of other common web technologies a foundation for developing an Anti-‐CSRF solution with equivalent security and integration flexibility. 1.
CSRF Protection Must Support Stateless and Stateful Modes The solution must work with web applications that do and do not utilize session storage.
2.
CSRF Token Life Must Be Configurable Token life options supported by Stateless and Stateful modes must be configurable.
3.
CSRF Token Protection Scope Must Be Configurable It must be possible to configure the following: § White list of exempt URLs -‐ By default, a non-‐expired token will be considered valid for all application requests (i.e. site-‐wide protection). It must be possible to exempt specific URLs from site-‐wide CSRF token validation. § Black list of protected URLs – it must be possible to only protect specific URLs with a CSRF token
4.
API and Integration Documentation Must Be Provided The solution API and integration steps must be clearly documented.
5.
CSRF Tokens Should be User Specific The CSRF token should be tied to the authenticated user’s identity.
6.
CSRF Token Protection Scope Should Support Form Specific Protection The scope of protection can be configured so that a non-‐expired token is tied to a specific form. Note: This requirement is out of scope for this project however the feature is on the roadmap for a future version of the OSS SS Solution.
7.
Simple Integration with Existing Web Application Technology Stack The solution should adhere to the following principles to ensure it is as plug-‐n-‐play as possible: ü Designed as a library that can be referenced by existing applications ü Utilize core platform-‐level APIs and specifications ü Minimize use of 3rd party libraries ü Aim to limit code modifications to source code of the integrating application
Rev. 1/14/2014
1
OSS SS Solution Design and Implementation The proposed OSS SS solution will support Stateless HMAC and Stateful Session based Anti-‐CSRF protection patterns for developers to integrate into their applications. A typical web application architecture maintains session state with application servers (i.e. Tomcat, JBoss, etc). The Jsessionid “sticks” to the application server instance behind front-‐end web servers that are load balanced. Based on this information, the Stateful J2EE HttpSession based Anti-‐CSRF protection pattern will be enabled by default. For applications that do not support J2EE HttpSessions, the Stateless HMAC solution will be available through a configuration option. GDS intends to meet requirements 1-‐5 and 7 during this project. Requirement 6. CSRF Token Protection Scope Should Support Form Specific Protection is out of scope for this project. This feature is on the roadmap for a future version of the OSS SS Solution. The Anti-‐CSRF solution will be implemented as a J2EE Filter. Defining which URLs require CSRF protection will be configurable from the web application container web.xml file by mapping those URLs to the CSRF Filter. If the application is configured to pass all requests through the CSRF Filter, custom configuration will be provided to define URLs exempt from CSRF protection. The HttpServletRequest object will be used for setting and getting various token attributes. A Java Server Pages (JSP) tag library will be provided to help reduce code modifications needed when integrating with an application. The following code changes when integrating with an existing application are likely: § When using the HMAC based solution, an integratng application will need to set the user’s identity as an HttpServletRequest attribute. This would need to be added through a J2EE Filter that executes prior to our CSRF Filter. § If use of the provided JSP tag library is not possible, modification of presentation layer code (such as JavaScript) to ensure CSRF Token is passed where required. The solution will consolidate all token generation and verification logic into a utility class called from the CSRF Filter. In the event an application does not support J2EE Filters or cannot utilize the CSRF Filter due to their architecture, the utility class could be used to develop a customized CSRF solution tailored to that application. Cryptography Considerations for HMAC Based Solution Each application will have its own HMAC key. In a server farm scenario, the application specific key will need to be stored on each application server instance. This will provide each application server with the ability to generate and validate the CSRF tokens. The planned solution will leverage the Google Keyczar 1 open source cryptographic toolkit to handle the HMAC signature creation, verification, and key management. Keyczar provides a high-‐level crypto API for seamlessly handling nuances with performing cryptographic operations. Refer to Cryptographic Design and Implementation Notes for additional information.
1 http://www.keyczar.org/ Rev. 1/14/2014
2
Feature Roadmap The following features are out of scope for this project, however they are on the roadmap for future development efforts: § Support for alternate protection schemes, such as Double Cookie Submit protection pattern § Support for token scoped to a form and the related token life configuration option Refer to Specs-‐GDS.xlsx for a high level overview of the features in and out of scope for this project. The protection Mode as well as Token Scope and Token Life supported by that mode will be configurable.
Rev. 1/14/2014
3
Cryptographic Design and Implementation Notes The following is only applicable to the HMAC based Anti-‐CSRF solution. Key Generation and Storage Keyczar keys are generated using the KeyczarTool utility which is a standalone JAR file. The tool ensures that the crypto keys are generated in a secure manner. The keys used by the CSRF solution are dependent on the application since it will be defined based on the signing key which is generated. The default signing key size in Keyczar is 256 bits. The keys are stored within a text file. It will be up to the integrator to place the file on the deployment server and protected from unauthorized access. The key file location will then need to be added to the Anti-‐CSRF solutions configuration file. Key Rotation Keyczar contains built-‐in support to implement key rotations. Each signature generated by Keyczar will contain a header which indicates which key was used to perform the signing. This provides the flexibility of defining multiple keys and promoting, demoting and revoking keys as needed through the KeyczarTool. Signature Generation and Verification The signature is generated using the Signer.sign method. The default HMAC algorithm used by Keyczar is SHA-‐1. The verification will be performed by using the Signer.verify method. It should be noted that the Keyczar.verify method performed constant-‐time comparisons and would therefore not be susceptible to timing attacks. For additional documentation on the Keyczar library refer to the following document: http://keyczar.googlecode.com/files/keyczar05b.pdf
Jan 14, 2014 - will be specific to J2EE web application architectures, these requirements ... of other common web technologies a foundation for developing an Anti-âCSRF solution with .... http://keyczar.googlecode.com/files/keyczar05b.pdf.
Ensure that â_blankâ is set as the destination within the HTML code. â All HTML5 .... Templates Google Drive required, please email if you require. â The Skin ...
cumbersome tool to have to port to mobile application clients. 4. Page 7. Description of Components .1 Odin-CLI .1.1 Technologies. The command line interface will be implemented in Python 3, using built-in classes and libraries to provide a usable in
This section describes the scope of Project Odin, as well as an overview of the contents of the SRS doc- ument. ... .1 Purpose. The purpose of this document is to provide a thorough description of the requirements for Project Odin. .... Variables. â
System Requirements Specification. Project Odin. Kyle Erwin. Joshua Cilliers. Jason van Hattum. Dimpho Mahoko. Keegan Ferrett. Note: This document is constantly under revision due to our chosen methodology, ... This section describes the scope of Pro
In the course of the project, we expect you to complete the following tasks: 1) Gather ... The presentations should target a non-technical audience and serve the ...
associations of the movie. This includes cast, director & Oscar awards management. All entities & relation are exposed via ... Our web client is written in HTML5, JavaScript ES2017 & CSS3. We're using Polymer which is a JavaScript library that helps
participation in Medicare and Medicaid funding. It describes every aspect and service of a ... also provides information straight from. CMS's Internet-Only Manual.
cohorts that were part of larger studies) and (5) the study represented an ..... Department of Health and Human Services. 1-166 (2011). (16) Shuldiner, A.R. et al. The Pharmacogenomics Research Network Translational Pharmacogenetics.
Jul 17, 2015 - They call such method as semi-supervised learning. ... 2. calculate the pdf/cdf of each median relevance level, 1 is about 7.6%, 1 + 2 is ..... Systems: Proceedings of the 2011 Conference (NIPS '11), pages 2546â2554, 2011.
Must be pulled high (3.3v). CS. 15. Any free pin. REST. 17. Any free pin. ITDB02 pinout. 1. All boards with pinout like the Arduino Duemilanove / Arduino UNO. 2.
solvency, the logic behind calls for higher capital requirements is awed. The ... to multiple rather than limited liability. Similar to the United States, Canadian. 3 ..... One way to alter bank incentives is to impose some form of contingent liabili
May 10, 2017 - We review over a decade of technology evolution and advancement of intra-datacenter optical interconnect, mainly driven by the explosive bandwidth growth of web and cloud-based services. Emerging trends and tech- nology options to scal
Software Project, Risk management, Software Tool, Effort, Risk, Budget ... Sales risk â building a product that the sales force doesn't understand how to sell.