University of West Bohemia Faculty of Applied Sciences Department of Computer Science and Engineering Master’s Thesis EEG/ERP Portal Security in New Technologies Pilsen, 2012 Jiří Novotný Declaration of Authorship I hereby declare that this master’s thesis is completely my own work and that I used only the cited sources. Pilsen, 17 May 2012 Jiří Novotný Abstract Security needs to be assured in EEG/ERP Portal for technical and legal reasons. The application stores sensitive data and has to be resistant against malicious ac- tions. This thesis describes improving security by using features introduced in new technologies and by patching exploitable weaknesses. First, background informa- tion including legal aspects, project description and security principles are provided. Then the process of technology migration is described, including tools introduced to enable the transition. Following a security analysis, the authentication process is restructured and revealed authorization shortcomings are fixed. The final configu- ration is tested and evaluated to make sure the portal is suitable for wide use. Contents 1. Introduction 1 I. Theoretical Background 2 2. Legal Aspects of Storing Neuroinformatic Data 3 2.1. EU Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Special Categories . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. Data Controllers . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3. Security Of Processing . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Czech Law Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Personal Data Protection in the U.S. . . . . . . . . . . . . . . . . . . 7 3. EEG/ERP Portal 8 3.1. Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Data Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. Application Tier . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.3. Presentation Tier . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Authentication and Authorization Solutions 12 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Remember Me . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2. Password Storage . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. Third Party Login . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Page-level Security . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Individualized Views . . . . . . . . . . . . . . . . . . . . . . . 15 i Contents 5. Frameworks Used in EEG/ERP Portal 17 5.1. Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. New Features in Spring 3.0 . . . . . . . . . . . . . . . . . . . . 18 5.1.2. Backward Compatibility . . . . . . . . . . . . . . . . . . . . . 18 5.2. Spring Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.1. New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.2. Backward Compatibility . . . . . . . . . . . . . . . . . . . . . 20 5.3. Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 II. Design and Implementation 22 6. Migration Plan 23 6.1. Blocks to a Direct Update . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1.1. Library Structure . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1.2. Absence of Tests . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Introducing Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2.1. Tool Description . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.2.2. Artifact Repositories . . . . . . . . . . . . . . . . . . . . . . . 27 6.3. Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Technology Update 29 7.1. Project Directory Structure Changes . . . . . . . . . . . . . . . . . . 29 7.2. Unifying Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3. Storing Custom Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.4. Porting JSON Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5. Building in Major IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.6. Command Line Support . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. Analyzing Security Loopholes 35 8.1. Password Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Error Stack Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.3. Unverified Address Inputs . . . . . . . . . . . . . . . . . . . . . . . . 36 8.4. Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.5. Authorization Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.6. Cookies Accessible to Scripts . . . . . . . . . . . . . . . . . . . . . . . 37 ii Contents 9. Restructuring Authentication Mechanism 38 9.1. Unifying Account Manipulation . . . . . . . . . . . . . . . . . . . . . 38 9.2. Securing Database Password Storage . . . . . . . . . . . . . . . . . . 38 9.3. Email as Primary Identification . . . . . . . . . . . . . . . . . . . . . 40 9.4. Single Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 9.5. Removing Plain Text Passwords . . . . . . . . . . . . . . . . . . . . . 42 10.Fixing Authorization and Mitigating Risks 43 10.1.Page Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.1.1. Proposed Design Improvement . . . . . . . . . . . . . . . . . . 43 10.2.Conditional Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.3.Protecting URL Parameter Input . . . . . . . . . . . . . . . . . . . . 45 10.4.Specifying Default Error Behavior . . . . . . . . . . . . . . . . . . . . 45 10.5.Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.6.HTTPOnly Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 11.Testing 47 11.1.Test Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11.2.Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 11.2.1. Fixing Existing Tests . . . . . . . . . . . . . . . . . . . . . . . 48 11.2.2. New JUnit Tests . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.3.Integration Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.3.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 11.3.2. Testing Authentication Setup . . . . . . . . . . . . . . . . . . 51 11.3.3. User Authorization Tests . . . . . . . . . . . . . . . . . . . . . 52 12.Evaluating Application Security 53 12.1.Web Application Security Scanners . . . . . . . . . . . . . . . . . . . 53 12.2.Comparing with Previous Evaluation . . . . . . . . . . . . . . . . . . 55 13.Conclusion 57 List of Abbreviations 58 Bibliography 60 CD Contents 63 iii 1. Introduction Security is of key importance in web applications. That is particularly true for a publicly accessible system storing personal and medical data, like EEG/ERP Portal developed at the University of West Bohemia. The application is designed to man- age measurement and experiment data created while using electroencephalography (EEG) and event related potentials (ERP) in attention research. The project is in active development for three years. Legal compliance, security and resistance against common attacks were already evaluated in a thesis by Jiří Vlašimský [1]. However, due to time constraints and technical limitations, not all possible measures for improving security were taken and new issues were revealed since. This thesis starts where the last one left off. Proposed changes form the basis for new tasks to be done, while other objectives arise from the current needs. Two main goals are to be met: Upgrading project technologies and enhancing secu- ritydesign. UpdateofframeworksusedbyEEG/ERPPortalalonewouldpotentially increase resistance against common threats, as vulnerabilities were found in older versions of the libraries. But possibly more importantly, new technology solutions were introduced in the current versions. Those can be used to improve application security, in some cases even rendering previously dangerous attacks impractical. The thesis will first evaluate aspects of storing neuroinformatic data under the leg- islation of European Union with emphasis on the Czech law, and the same in the United States. Then the EEG/ERP Portal application is introduced. Another chapter will describe authentication and authorization solutions available in frame- works utilized by the project. Also current generations of the frameworks will be introduced, emphasizing new features. The realization phase will focus on migrat- ing to new technologies, analyzing security shortcomings, improving authentication, authorization and other security features, testing and evaluating the results. 1 Part I. Theoretical Background 2 2. Legal Aspects of Storing Neuroinformatic Data Large amounts of data are produced during research in the field of neurology. Re- strictions and limitations exist for data analyzing and processing, the nature of which is not only technical, but also legal. As personal details and medical records are used, data handling must be compliant with personal data protection laws. EEG/ERP Portal introduced later in chapter 3 is an application storing this kind of information. It is therefore important to ensure compatibility with the legislative in personal data protection and other aspects. A thorough legal analysis of storing medical data is both outside the thesis author’s professional abilities, and outside the scope of this chapter. With that in mind, only selected paragraphs relevant for the described domain will be cited to clarify, what is defined as personal and sensitive information, what actions must be taken before such information is processed and what rules need to be followed when storing the data. Legal aspects will be discussed using an EU directive implemented in the legal systems of member countries and by listing applicable Czech laws. Practices based in U.S. legislation will be included for comparison. 2.1. EU Directive Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data offers a definition of the personal information [2, Article 2]: ’Personal data’ shall mean any information relating to an identified or identifiable natural person (’data subject’); an identifiable person is one 3 2.1 EU Directive who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity Personal data may be processed only if certain conditions are met. Among others, that can be when [2, Article 7]: The data subject has unambiguously given his consent; or Processing is necessary for the purposes of the legitimate interests pur- sued by the controller or by the third party or parties to whom the data are disclosed, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject which require protection under Article 1 A person can take part in the EEG research as a test subject only after signing a written consent with processing personal data (the agreement text can be found in [1]), so there is no conflict with the principle in EEG/ERP Portal. 2.1.1. Special Categories Certain data types are, by default, not allowed to process [2, Article 8, Paragraph 1]: Member States shall prohibit the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical be- liefs, trade-union membership, and the processing of data concerning health or sex life. However, the restriction does not apply in several cases, one of which is again an explicitly given consent [2, Article 8, Paragraph 2]: Paragraph 1 shall not apply where: a) The data subject has given his explicit consent to the processing of those data, except where the laws of the Member State provide that the prohibition referred to in paragraph 1 may not be lifted by the data sub- ject’s giving his consent 4