TABLE OF CONTENTS

TABLE OF CONTENTS ............................................................................................................... 1

A. INTRODUCTION ...................................................................................................................... 2

B. THE GIAC SECURE SOFTWARE PROGRAMMER (GSSP) EXAMINATION ....................... 2

C. DEADLINES AND EXAMINATION SCHEDULE ..................................................................... 3 D. REGISTRATION FEES ............................................................................................................ 3 E. REGISTRATION PROCESS .................................................................................................... 3 F. ELIGIBILITY REQUIREMENTS ............................................................................................... 4 G. EXAMINATION INFORMATION .............................................................................................. 4

Examination Development ..................................................................................................... 4 Examination Content .............................................................................................................. 4 Reference List ......................................................................................................................... 4 Practice Test ........................................................................................................................... 4 Examination Time Limits ....................................................................................................... 5 Certification ............................................................................................................................. 5 Additional Certification Information ..................................................................................... 5

H. SAMPLE QUESTIONS AND ANSWERS ............................................................................... 6 Appendix A: Java/Java EE Essential Skills and Implementation Issues ............................. 11 Appendix B: Helpful Resources .............................................................................................. 16

Book References for Software Security ............................................................................. 16

1

Websites & Podcasts for Software Security ...................................................................... 17

2

A. INTRODUCTION Governments, companies, and educational institutions are doomed to deal with endless streams of software vulnerabilities unless programmers learn to write much more secure code. Several initiatives are underway to improve secure programming skills and knowledge. Symantec, Oracle, Microsoft, and a few other software companies are conducting short courses for their programmers; software firms like SPI Dynamics and Fortify Technology are working with universities to provide automated, real-time feedback to student programmers; and dozens of universities are creating elective courses on secure programming. Yet, even if all of those initiatives are successful, they are unlikely to affect even two percent of the existing 1.5 million programmers already in the work force or those who will be entering the work force over the next five years. To answer this growing need, the SANS Institute, in connection with the Global Information Assurance Certification (GIAC) organization, has organized a testing and certification program for software programmers/developers that is designed to enable reliable measurements of technical proficiency and expertise in identifying and correcting the common programming errors that lead to security vulnerabilities.

SANS is the most trusted and by far the largest source for information security training and certification in the world. It also develops, maintains, and makes available at no cost, the largest collection of research documents about various aspects of information and software security, and it operates the Internet's early warning system - Internet Storm Center. SANS provides intensive, immersion training designed to help candidates master the practical steps necessary for defending applications, systems and networks against the most dangerous threats - the ones being actively exploited.

The GIAC Certification Program

http://www.giac.org Founded in 1999 to validate the real-world skills of IT security professionals and developers, GIAC stands for Global Information Assurance Certification. GIAC's purpose is to provide assurance that a certified individual has practical awareness, knowledge, and skills in key areas of computer, network and application/software security. These certifications are available for a variety of responsibilities that reflect the current practice of information security and secure software development. GIAC is unique in measuring specific knowledge areas instead of general purpose knowledge. B. THE GIAC SECURE SOFTWARE PROGRAMMER (GSSP) EXAMINATION http://www.giac.org/certifications/software/ The GIAC Secure Software Programmer (GSSP) allows candidates to demonstrate mastery of the knowledge and skills needed to deal with common programming errors that lead to most security problems in one or more specific languages:

• Java and JAVA EE • C • C++

• PHP • Perl • ASP.NET and .NET

The examinations are primarily for programmers/developers who develop and maintain code. Those involved with software code review/audit, QA and testing will also be able to demonstrate valuable skills. The exams focus on the common errors that programmers make that lead to vulnerabilities. They target implementation issues in individual programming languages as well as secure programming principles that are directly relevant to every day coding activities. In contrast to tests that measure book learning, this test measures an individual’s ability to identify coding errors and to apply the widely accepted rules and recommendations that constitute the core of secure coding. Many of the test questions use code samples in which the test taker is asked to find errors and decide how to eliminate them. C. DEADLINES AND EXAMINATION SCHEDULE The GSSP is administered at established proctored testing facilities. For full information on the GIAC proctor program, please see http://www.giac.org/proctor/. Once you have completed the registration process and receive access to your certification, you will have (4) months to complete your certification. D. REGISTRATION FEES The GSSP-J is currently available through the GIAC Challenge Certification program. The Challenge Certification registration fee for the GSSP-Java is $899.00. The registration fee for the GSSP-Java with the corresponding SANS training course is $499.00.

Payments may be made via Visa, MasterCard, money order, cashier’s check, or personal check. The fee must be paid in U.S. funds. The application fee is non-refundable and must be received by SANS for your registration to be complete. E. REGISTRATION PROCESS The registration steps include: 1. It is suggested that you review the candidate handbook prior to completing registration.

Follow the instructions given, and address any questions to GIAC (info@giac.org). Failure to follow the instructions can lead to the denial of registration.

2. You must have a SANS portal account to register. If you do not have a portal account, you

may create one by visiting https://portal.sans.org/. 3. Once you have a SANS portal account you may register for the GSSP Challenge certification

by visiting the following link and selecting the GIAC Secure Software Programmer-Java (GSSP-Java) offering.

https://www.sans.org/registration/register.php?conferenceid=1251

3

The registration fee for the GSSP-Java with the corresponding SANS training course is $499.00. For information regarding this please see: http://www.giac.org/certifications/software/gssp-java.php Please note that registration for the GSSP examination may be refused or GIAC certification may be revoked for any of the following reasons:

• Incomplete registration • Falsifying or misrepresenting registration information • Adjudicated penalty for violation of the GIAC Code of Ethics

If you are notified of revocation, you will also be notified of the available appeal process. F. ELIGIBILITY REQUIREMENTS There are no eligibility requirements to register for the GSSP. G. EXAMINATION INFORMATION

Examination Development The development of a valid GSSP examination began with a clear and concise definition of the knowledge, skills, and abilities needed for competent job performance. Using interviews, surveys, and group discussions, SANS worked with subject matter experts to delineate critical job components. The knowledge and skill bases for the questions on the multiple-choice examination were derived from the actual practice of software programmers. Specifically, the GSSP is built in three stages. First the team agrees on the tasks and rules that a secure programmer uses in each language. Then they rank those tasks and rules on three criteria: criticality of risk if the rule is broken, importance of the rule, and frequency with which the rule should be employed. Using those ratings they compute the number of questions that will be on the test for each task/rule set. Finally they develop and vet questions. This ensures that the questions will adequately reflect the actual importance of the rules being tested.

Examination Content The certification examination consists of 100 multiple-choice questions. The full content blueprint can be found in Appendix A. As noted in the ‘Exam Development’ section above, experts have provided input for the difficulty level of all questions used on the exams. That information is used to develop examination forms that have comparable difficulty levels.

Reference List

A reference list of potential study materials is located in Appendix B. Some of the material will be helpful in preparing for the assessments. This is not intended as a complete list or an endorsement, but simply as a starter for those interested in learning more.

Practice Test Two practice exams are provided with GSSP certification attempts.

4

Examination Time Limits You will be given four (4) hours to complete the test.

Certification Those who gain passing scores at the foundation level will earn the GIAC Secure Software Programmer (GSSP) certification. A designation will follow the letters reflecting the language in which the certification was earned. For example, a programmer who passes the Java exam would receive the GSSP-J designation. The GSSP certification will be valid for four years. You will become eligible to apply for re-certification one (1) year prior to your certification expiration. You must register for re-certification before your certification expiration date. To re-certify, you must pass the current examination being offered.

Additional Certification Information For more information on the certification process, including our Proctoring Policy, GIAC Code of Ethics, Accommodations for Individuals with Disabilities, Examination Retakes, Scheduling your Exam and Test Taking Procedures, please visit the following sites: http://www.giac.org/ http://www.giac.org/proctor/ http://www.giac.org/information http://www.giac.org/GIAC_silver_handbook.pdf

5

6

H. SAMPLE QUESTIONS AND ANSWERS

Sample Questions 1) The Java synchronized keyword is important to security because of which of the following:

A. It allows two different functions to execute simultaneously. B. It prevents multiple developers from writing the same block of code. C. It allows the class to be loaded as soon as the JRE starts. D. It prevents multiple threads from accessing a block of code at the same time.

2) Which of the following is true and causes a security concern for Java inner classes?

A. Private members of the inner and outer classes are given package-visible accessor methods.

B. Final methods of either class can be extended. C. Inner classes are not recognized by the JVM, therefore they are translated to subclasses

of the containing class. D. Inner classes’ data members are cached in memory by the JVM for optimization.

3) When enabling your JAVA EE server application with SSL, which of the following must

occur?

A. The certificate be issued by a third-party Certificate Authority, I.e. Verisign. B. The certificate be signed either by a Certificate Authority or self-signed. C. The Sun cryptographic provider package be installed in your JVM. D. An offline key exchange be done with the client prior to SSL communications.

4) In a JAVA EE application using a JSESSIONID, which of the following does not help protect

the session?

A. Encrypting the communications that transmit the JSESSIONID. B. Storing the JSESSIONID as a session cookie instead of a permanent cookie. C. Validating the JSESSIONID to ensure it doesn’t contain meta characters. D. Making the JSESSIONID long and random.

Three Challenging Questions 5) If you had to choose only one, in which JAVA EE tier is it BEST to perform input validation?

A. Any tier, so long as it gets done properly. B. The enterprise (backend) tier, as this would prevent injection attacks into backend

systems like SQL-injection. C. The middle tier, as this is the front-door to your application’s resources. D. The client tier, as this is the front-door to your application and validation should be done

as soon as possible. 6) Java offers the PreparedStatement class which when used properly protects against SQL

Injection attacks. What is wrong with its use in the following code snippet that potentially enables an injection attack?

PreparedStatement stmt = con.prepareStatement

("SELECT ssn FROM usersTable WHERE “ + “name = “ + getParameter(“username”) );

ResultSet rs = stmt.executeQuery();

A. Because the user is able to specify the username they can change it to someone else’s username and access another user’s SSN.

B. The ‘username’ parameter is not being validated for dangerous content. C. The SQL string must be defined elsewhere, and then put into the PreparedStatment in

order for it to protect the query. D. The PreparedStatement is being used as a normal, dynamic SQL query. No data is

being entered via the safe substitution methods. 7) JAVA EE Filters can improve the security posture of an application for each of the following

reasons, EXCEPT:

A. Filters can be used to validate data in a JDBC database connection to protect against injection attacks.

B. Filters can be used to “wrap” a JAVA EE application, adding new security measures without modifying existing code.

C. Filters can modify incoming requests to the application, allowing input validation and other security operations to occur.

D. Filters can modify outgoing responses from the application, allowing header-rewriting and other security operations to occur.

7

Two Difficult Questions 8) Consider the following ‘Session Fixation’ attack scenario:

An attacker browses to a website and receives a JSESSIONID without logging in. Then embeds that ID in a link and emails it to a victim. The victim clicks on the link and proceeds to login, using the JSESSIONID that is known by the attacker. The attacker can now masquerade as the victim.

Which of the following BEST mitigates this threat? A. Users should be instructed not to click on links in email. B. The application should provide a new JSESSIONID to each user when they authenticate. C. Users should be required to enter text that is represented in a garbled graphic, proving

they are human. D. The application server should be configured to expire the JSESSIONID very quickly to

reduce the window of opportunity. 9) Which of the following is NOT true about declarative JAVA EE access control as setup by the

web.xml file?

A. Developers must still use the isUserInRole method to restrict access between resources and roles that are declared in the web.xml file.

B. Wildcard patterns can be used to setup access restrictions across many different resources at once.

C. Roles can be linked, allowing roles to be equivalent to or supersets of other roles. D. Individual methods within EJBs can be restricted to certain roles, which ultimately

restricts the end users that can access the method.

Two Additional Code Questions

10) The code snippet below should have a “finally” block, why?

File fid = new File(“C:/testfile”); try{ FileInputStream fis = new FileInputStream( fid ); … fid.close(); } catch ( Exception e ) { Logger.log(“Exception accessing file.”); }

A. It would allow the program to access debugging information if an exception were to occur. B. It would prevent other code in the JVM from trying to access the same resource. C. It would be the best place to perform the fid.close() function. D. It would ensure the program caught every possible type of exception that could come out

of that section of code.

8

11) The code snippet below performs an access control check for a Web user accessing a system object. Which of the following would meaningfully improve this mechanism?

//get account for which user wants details from the Request String rqstdId = request.getParameter(“ACCNT_ID”); //check that user is privileged to view the requested object boolean accessAllowed = false; String[] userAccountList = getAccountIds(user); for (int i=0; i<userAccountList.length; i++) { if (userAccountList[i].equals( rqstdId ) accessAllowed = true; } if ( accessAllowed == true ) { displayDetails( rqstdId ); } else { logAccessControlFailure(); }

A. The web interface should be redesigned to allow a unique URI for each requested account Id, so the Id is not treated as a parameter. This prevents a user from tampering with the parameter.

B. The user should not send in a reference to the actual account Id. Instead they should make a selection from indices that are mapped to the actual accounts they have access to. This prevents a user from tampering with an actual account Id.

C. The displayDetails() code should not be a separate method. Because the access control check was performed here, so should the actual access to the resource. This allows a code audit to verify that the access check directly controls the resource.

D. The accessAllowed boolean should be initialized to true, then set to false when known to be false. This would prevent an error from unintentionally restricting access to the object.

Sample Question Answers 1) Answer (D) It prevents multiple threads from accessing a block of code at the same time. Explanation: The synchronized keyword ensures that only one thread of execution is accessing a given block of code at a given time. The subtleties of concurrent programming are often overlooked by developers. 2) Answer (A) Private members of the inner and outer classes are given package-visible accessor methods. Explanation: Exp: Inner classes have no true representation in Bytecode. The inner and outer classes are simply compiled to have package-level visibility so they can see within one another. 3) Answer (B) The certificate be signed either by a Certificate Authority or self-signed. Explanation: In order for a certificate to be used for SSL protected communications, it must be signed.

9

4) Answer (C) Validating the JSESSIONID to ensure it doesn’t contain meta characters. Explanation: Validating the JSESSIONID might be useful, but it doesn’t help protect the data in the session, nor the secrecy of the session Id itself. 5) Answer (C) The middle tier, as this is the front-door to your application’s resources. Explanation: The middle tier is where your custom application resides. Validation must be done here to protect the logic and resources accessed by your application. Input from external applications or users cannot be trusted, so validation must occur in the middle tier to protect your resources. 6) Answer: (D) The PreparedStatement is being used as a normal, dynamic SQL query. No data is being entered via the safe substitution methods. Explanation: The PreparedStatement is Java’s implementation of a parameterized query. Parameterized queries are defined with place-holders for dynamic data to be substituted in. That substitution is not being done in the code snippet. 7) Answer: (A) Filters can be used to validate data in a JDBC database connection to protect against injection attacks. Explanation: Filters are an under-utilized capability in JAVA EE that have the ability to sit between your middle-tier application and the client-tier and operate on HTTP requests and responses. 8) Answer: (B) The application should provide a new JSESSIONID to each user when they authenticate. Explanation: Session Ids can be embedded in a link as described in the scenario and many applications don’t protect them with SSL until a user authenticates. But in both cases the session Id may have already been compromised. Therefore, it should not be used to represent an authenticated user; they should be issued a new one upon authentication. This is not, nor can it be, done by JAVA EE, it is the application developer’s responsibility. 9) Answer: (A) Developers must still use the isUserInRole method to restrict access between resources and roles that are declared in the web.xml file. Explanation: Declarative access control differs from programmatic access control in that all the rules, subjects, and resources are defined in a configuration file and is enforced by the JAVA EE system. If developers need to write more granular access control, that is referred to as programmatic access control. 10) Answer: (C) It would be the best place to perform the fid.close() function. Explanation: Code within a finally block is always executed after the try and a catch (if an exception is thrown) block are executed. This is the best place to close resources that are used in the try block, as you know it will always happen.

11) Answer: (B) The user should not send in a reference to the actual account Id. Instead they should make a selection from indices that are mapped to the actual accounts they have access to. This prevents a user from tampering with an actual account Id. Explanation: Many applications provide direct references to internal and backend resources. Whether the URL or a bank account Id, it is better to map the user’s requests for access to the actual resources. This would prevent the user from tampering with the reference to attempt to force-browse to another URL or resource. It also serves as a type of input validation by preventing user references from being sent to backend systems.

10

Appendix A: Java/JavaEE Essential Skills and Implementation Issues The Secure Programming Council’s Essential Skills for Secure Programmers Using Java/JavaEE November 2007 Introduction Criminal hackers are increasingly targeting web applications, as organizations ranging from TJ Maxx to the New Zealand government are acutely aware. Vulnerabilities in web applications give the attackers direct access to valuable personal information or other sensitive information that can be sold for money or used by national intelligence organizations. To blunt these attacks, most large organizations are establishing application security initiatives led by managers who have broad responsibility to use tools and training to ensure new and existing applications do not have security flaws, whether built in-house, outsourced, or at commercial software companies. More than 40 of these organizations are cooperating in establishing standards and metrics that they can use for measuring their application security programs – in essence a “minimum standard of due care” for secure programming. The group, called the Secure Programming Council, has just completed its first consensus document, called “Essential Skills for Secure Programmers Using Java/JavaEE,” and is making the document available for public comment. Once a 60 day comment period has been completed and the suggestions appropriately woven in, the Council will publish the Java Essential Skills document for all to use. The “Essential Skills” series is designed to enable organizations to ensure that the developers who write their applications can demonstrate that they have mastered secure programming. The council has additional minimum skills standards initiatives under way for C, C++, .NET languages, and PHP and PERL. When combined with an effective secure development life cycle, such skills can be enormously valuable in building more secure applications. Knowledge and skills are essential only in the context of tasks that programmers must complete, so this document is organized by the security-related tasks that programmers do regularly. The Secure Programming Council has created a set of standardize tests that measure these Essential Skills. These exams can be used in-house to find gaps in programmer skills, and for assessing job candidates, consultants, and outsourcing organizations. Parallel examinations are also available for on-line administration inside large organizations. A Community Effort: Your Input Is Welcome The Secure Programming Council Java and JavaEE steering committee is composed of six of the most skilled Java security people in the world. Ed Tracy of Booz Allen & Hamilton, Ryan Berg and Bruce Mayhew of Ounce Labs, Reza Kopaee of Deloitte and

11

Touche, Frank Kim of Kaiser Permanente, and Sherif Koussa of Firsthand Technologies. Assisting the steering committee are a team of equally impressive people: Jeff Williams and

Dave Wichers of OWASP, Brook Connor of Morgan Stanley, Sanjay Bahl of Tata Consulting, Justin Schuh of Neohapsis, Dave Grant of Watchfire, Erik Cabetas of Fortify, Jesper Johansson of Amazon, Vincent Liu of Stach & Liu, and Rohit Sethi and Nishchal Bhalla of Security Compass. They all welcome suggestions from interested testers and programmers on the front lines. Please send comments to spa@sans.org. Comments will shape future versions.

12

 

GSSP (GIAC Secure Software Programmer) 

  

Java/Java EE Implementation Issues

13

Task 1: Input Handling - Java programmers must be able to write programs that read input from their interfaces and properly validate and process these inputs including command line arguments, environment variables, and input streams. As these sources may ultimately derive from user input or other untrusted sources, Input Handling has security repercussions. 01.1.1 Input Validation Principles - Java programmers must understand that input cannot be trusted, regardless of the interface, i.e., HTTP Requests, Applet sockets, serialized streams, configuration files, backend datastores, etc. Java programmers must understand the white-list approaches and black-list approaches and the tradeoffs between them.

01.1.2 Input Validation Sources - Java programmers must recognize common sources of input to Java applications. This enables them to know when to question the trust level of certain data and weigh it to decide if input validation is warranted. 01.1.3 Input Validation Techniques - Java programmers must understand how to validate common data types such as String data as well as uncommon input structures. Familiarity with Regular Expressions, doValidate() and other tools of Java and J2EE to perform input validation are required.

Task 2: Authentication & Session Management - Java application programmers must have a basic understanding of Java and J2EE authentication APIs as well as a mastery of authentication principles for local and remote applications. For the purposes of this examination, Session Management is considered the process of maintaining an end-user’s authenticated identity for an extended period. It is required that Java programmers understand the threats to common authentication and session management operations in order to properly protect these operations. 01.2.1 When to Authenticate - Java programmers must understand that authentication is needed not only for end-users, but also 3rd party services, backend systems, etc.

01.2.2 Authentication Protection - Java programmers are required to know how to use encryption and certificates to protect various authentication processes. This includes an understanding of strength-of-function, credential expiration, credential recovery/reset, and re-authentication. 01.2.3 Session Protection. For the protection of session tokens, Java programmers are required to understand the implications of several topics, including encryption, strength-of-function, lifespan of tokens, and re-issuance. 01.2.4 Rule 4: Authentication Techniques - Java programmers must be familiar with the more common authentication techniques and APIs available within Java and J2EE technologies. This includes the Java Authentication and Authorization Services (JAAS), backend credential storage, and various front-end authentication alternatives such as certificate, forms, and basic authentication. This familiarity assumes the programmer will understand the threats and tradeoffs for each technique.

01.2.5 Authentication Responsibilities - Java programmers must have a complete understanding of what services and protections are provided by using common APIs and what is not provided. For example, maximum session length, re-authentication, and encryption are protections that are not enabled automatically.

14

Task 3: Access Control (Authorization) - Java application programmers must be able develop applications that guarantee the confidentiality of user data. These applications must also prevent users from performing certain functions. Developers must understand that access control must actively be enforced, not ignored or left to backend systems. 01.3.1 Restricting Access to Resources - Java developers must understand the need for a clear and complete access control policy for system resources: for example, user data objects that should only be accessed by the owner of the data. 01.3.2 Restricting Access to Functions - Java developers must understand the need to restrict access to functions such as privileged functions and privileged URIs, etc. 01.3.3 Declarative Access Control - An understanding of the common APIs (and their tradeoffs) that support access control according to configuration files. 01.3.4 Programmatic Access Control - Java developers must understand how and when to manually perform access control checks in their custom code. 01.3.5 JAAS - Java developers must understand how the Java Authentication and Authorization Service can be used to implement access control. Task 4: Java Types & JVM Management - Java programmers must understand the security implications of built-in data types and Java-specific memory management. 01.4.1 java.lang.String - Java programmers must have a complete mastery of the String class’s immutability and how to compare String objects. 01.4.2 Integer and Double Overflows - Java programmers must under-stand the limitations of Java’s numerical data types and the resulting security implications. 01.4.3 Garbage Collector - Java programmers must have an understanding of how the Java Garbage Collector works and the resulting security implications. 01.4.4 ArrayList vs Vector - Java programmers must understand the differences and the resulting security considerations between the ArrayList and the Vector. 01.4.5 Class Security - Java programmers should be familiar with accessibility modifiers, the final modifier, class comparisons, serialization, clone-ability, and inner classes. 01.4.6 Code Privileges - Java Programmers must understand how to manage the privileges of code as well as the different protection domains. This includes an understanding of the Security Manager and its policy file.

Task 5: Application Faults & Logging - All Java application programmers need to be able to properly handle application faults. 01.5.1 Exception Handling - Java application developers must understand Java’s try/catch/finally construct to appropriately handle application and system exceptions. Developers must determine how much information should be logged when an exception is encountered depending on the nature of the exception. 01.5.2 Logging - Developers must understand the principles behind logging security-relevant events such as login, logoff, credential changes, etc. Developers should also be familiar with Java’s logging package, java.util.logging. 01.5.3 Configuration of Error Handling - J2EE developers should be familiar with the configuration to return a default error page for HTTP 404 and 500 errors. Task 6: Encryption Services - Java programmers must understand when and how to use encryption to protect sensitive data. 01.6.1 Communications Encryption - Java application developers must be familiar with the Java Secure Sockets Extension (JSSE) packages as well as how to configure SSL communication for J2EE applications. Developers are also responsible for knowing which of their application’s external links should be protected with encryption.

01.6.2 Encryption of Data at Rest - Java developers must understand how to store sensitive data in encrypted format. Task 7: Concurrency and Threading - Java programmers must understand how to properly structure multi-threaded programs. 01.7.1 Race Conditions - All Java application developers must understand race conditions and how they affect system security. This includes avoiding caching security relevant information that can be accessed by multiple threads. 01.7.2 Singletons & Shared Resources - Java developers must understand how to implement the Singleton pattern in Java and how to protect other resources that are accessed by multiple threads.

Task 8: Connection Patterns - Java programs must be able to securely interface with other applications. Developers must be familiar with parameterized queries, output encoding, and fail-safe connection patterns. 01.8.1 Parameterized Queries / PreparedStatements - Java programmers must understand the security risks introduced by using dynamic queries and how to safely use the PreparedStatement to safely and securely interact with databases based on user-supplied input. 01.8.2 Output Encoding - Java programmers must understand when and how to use output encoding to display data to user interfaces, as this is a primary mitigation technique to UI injection attacks, e.g. Cross-site Scripting. 01.8.3 Fail-safe Connection Patterns - Java programmers must properly form connection patterns using Java’s try/catch/finally to prevent resource leaks. Resource leaks can occur as a result of failures while operating with connections to external systems. Task 9: Miscellaneous 01.9.1 Class/Package/Method Access Modifiers - All Java programmers must understand how the Java access modifiers (public, private, protected) can be used to protect class members and methods. 01.9.2 Class File Protection - Java programmers must understand how JAR sealing is used. 01.9.3 J2EE Filters - J2EE programmers must be familiar with J2EE Filters and how they can be used to implement many of the tasks listed above.

15

Appendix B: Helpful References

Below is a list of some material that will help programmers and security professionals learn more about secure programming. Some of the material will also be helpful in preparing for the assessments. This is not intended as a complete list or an endorsement, but simply as a starter for those interested in learning more.

Book References for Software Security: 19 Deadly Sins of Software Security

Michael Howard, David LeBlanc, John Viega Building Secure Software: How to Avoid Security Problems the Right Way

John Viega, Gary McGraw Exploiting Software: How to Break Code

Gary McGraw, Greg Hoglund Foundations of Security: What Every Programmer Needs to Know

Neil Daswani, Christoph Kern, Anita Kesavan Introduction to Computer Security

Matt Bishop J2EE & Java: Developing Secure Web Applications with Java Technology (Hacking Exposed)

Art Taylor, Brian Buege, Randy Layman Secure Coding in C and C++

Robert Seacord Secure Coding: Principles and Practices

Ken Van Wyk, Mark Graff Hacking Exposed: Web Applications

Scambray, Shema, Sima Secure Programming Cookbook for C and C++

John Viega, Matt Messier Security and Usability

Simson Garfinkel, Lori Faith Cranor Software Security: Building Security In

Gary McGraw The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities

16

Mark Dowd, John McDonald, Justin Schuh

17

The Security Development Lifecycle

Michael Howard, Steve Lipner Web Security, Privacy & Commerce, Second Edition

Simson Garfinkel, Gene Spafford Writing Secure Code, Second Edition

Michael Howard, David C. LeBlanc Websites & Podcasts for Software Security: OWASP - Open Web Application Security Project

http://www.owasp.org/index.php/Main_Page Microsoft Corporation - Security Developer Center

http://msdn2.microsoft.com/en-us/security/aa570401.aspx MITRE - Common Weakness Enumeration (CWE)

http://cwe.mitre.org/ CERT - Secure Coding Initiative

http://www.cert.org/secure-coding/