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
Websites & Podcasts for Software Security ...................................................................... 17

1
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 • PHP
• C • Perl
• C++ • ASP.NET and .NET

2
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
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.

6
 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
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

11
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
 
 
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.

13
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.

14
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
Mark Dowd, John McDonald, Justin Schuh

16
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/

17