The Open Web Application Security Project Owasp

Code Review Guide V11 Matteo Meucci download

https://ebookbell.com/product/the-open-web-application-security-
project-owasp-code-review-guide-v11-matteo-meucci-2223312

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

The Open Web Application Security Project Owasp Testing Guide V30
Matteo Meucci

https://ebookbell.com/product/the-open-web-application-security-
project-owasp-testing-guide-v30-matteo-meucci-2223306

Zk Developers Guide Developing Responsive User Interfaces For Web

Applications Using Ajax Xul And The Open Source Zk Rich Web Client
Development Framework Markus Staeuble

https://ebookbell.com/product/zk-developers-guide-developing-
responsive-user-interfaces-for-web-applications-using-ajax-xul-and-
the-open-source-zk-rich-web-client-development-framework-markus-
staeuble-1373932

The Semantic Web Research And Applications 6th European Semantic Web
Conference Eswc 2009 Heraklion Crete Greece May 31june 4 2009
Proceedings 1st Edition James A Hendler Auth

https://ebookbell.com/product/the-semantic-web-research-and-
applications-6th-european-semantic-web-conference-eswc-2009-heraklion-
crete-greece-may-31june-4-2009-proceedings-1st-edition-james-a-
hendler-auth-2040164

The World Is Open How Web Technology Is Revolutionizing Education 1st

Edition Curtis J Bonk

https://ebookbell.com/product/the-world-is-open-how-web-technology-is-
revolutionizing-education-1st-edition-curtis-j-bonk-2536428
The World Is Open How Web Technology Is Revolutionizing Education
Curtis J Bonkauth

https://ebookbell.com/product/the-world-is-open-how-web-technology-is-
revolutionizing-education-curtis-j-bonkauth-4314240

The Cosmic Web Scientific Field Models And Literary Strategies In The
Twentieth Century N Katherine Hayles National Endowment For The
Humanities Open Book Program

https://ebookbell.com/product/the-cosmic-web-scientific-field-models-
and-literary-strategies-in-the-twentieth-century-n-katherine-hayles-
national-endowment-for-the-humanities-open-book-program-51832700

Programming For The Web From Soup To Nuts Implementing A Complete Gis
Web Page Using Html5 Css Javascript Nodejs Mongodb And Open Layers
Charles W Kann Iii

https://ebookbell.com/product/programming-for-the-web-from-soup-to-
nuts-implementing-a-complete-gis-web-page-using-html5-css-javascript-
nodejs-mongodb-and-open-layers-charles-w-kann-iii-42892464

Open Tv Innovation Beyond Hollywood And The Rise Of Web Television

Aymar Jean Christian

https://ebookbell.com/product/open-tv-innovation-beyond-hollywood-and-
the-rise-of-web-television-aymar-jean-christian-51759830

Open Tv Innovation Beyond Hollywood And The Rise Of Web Television

Aymar Jean Christian

https://ebookbell.com/product/open-tv-innovation-beyond-hollywood-and-
the-rise-of-web-television-aymar-jean-christian-11657252
OWASP
The Open Web Application Security Project

Code Review Guide, V1.1

release

Creative Commons (CC) Attribution Share-Alike

CC Free version at http://www.owasp.org
OWASP CODE REVIEW
GUIDE
2008 V1.1

© 2002-2008 OWASP Foundation

This document is licensed under the Creative Commons Attribution Share Alike 3.0 license. You must
attribute your version to the OWASP Code Review Guide or the OWASP Foundation.
 OWASP Code Review Guide V1.1 2008

Table of Contents

Foreword by Jeff Williams, OWASP Chair................................................................................................................... 4

Welcome to the OWASP Code Review Guide 1.1 .................................................................................................. 6

About The Open Web Application Security Project ............................................................................................... 8

Code Review Guide History ....................................................................................................................................... 10

Introduction ................................................................................................................................................................... 11

Preparation.................................................................................................................................................................... 13

Security Code Review in the SDLC ........................................................................................................................... 17

Security Code Review Coverage ............................................................................................................................. 19

Application Threat Modeling ..................................................................................................................................... 23

Code Review Metrics .................................................................................................................................................. 47

Crawling code .............................................................................................................................................................. 52

Searching for code in J2EE/Java .............................................................................................................................. 60

Searching for code in Classic ASP ............................................................................................................................ 64

Javascript / Web 2.0 keywords and pointers.......................................................................................................... 67

Code review and PCI DSS .......................................................................................................................................... 68

Reviewing by technical control: Authentication ................................................................................................... 70

Reviewing by technical control: Authorization ...................................................................................................... 77

Reviewing by technical control: Session Management ....................................................................................... 83

Reviewing by technical control: Input Validation ................................................................................................. 87

Reviewing by technical control: Error Handling ..................................................................................................... 90

Reviewing by technical control Secure application deployment ................................................................... 105

Reviewing by technical control Cryptographic controls ................................................................................... 109

Reviewing Code for Buffer Overruns and Overflows........................................................................................... 122

2
 OWASP Code Review Guide V1.1 2008

Reviewing Code for OS Injection ............................................................................................................................ 127

Reviewing Code for SQL Injection .......................................................................................................................... 132

Reviewing Code for Data Validation ..................................................................................................................... 138

Reviewing Code for Cross-site scripting................................................................................................................. 153

Reviewing code for Cross-Site Request Forgery issues........................................................................................ 160

Reviewing Code for Logging Issues ........................................................................................................................ 165

Reviewing Code for Session Integrity issues .......................................................................................................... 170

Reviewing Code for Race Conditions.................................................................................................................... 173

Additional security considerations:......................................................................................................................... 175

Java gotchas .............................................................................................................................................................. 176

Java leading security practice................................................................................................................................ 183

Classic ASP Design Mistakes ..................................................................................................................................... 186

PHP Security Leading Practice................................................................................................................................. 190

Strings and Integers.................................................................................................................................................... 193

Reviewing MySQL Security........................................................................................................................................ 197

Reviewing Flash Applications................................................................................................................................... 200

Reviewing Web services ........................................................................................................................................... 203

How to write an application code review finding............................................................................................... 206

Automated Code revieW......................................................................................................................................... 209

Tool Deployment Model ........................................................................................................................................... 210

The Owasp Orizon Framework ................................................................................................................................. 211

The Owasp Code Review Top 9 .............................................................................................................................. 223

Guide References ...................................................................................................................................................... 232

3
 OWASP Code Review Guide V1.1 2008

FOREWORD BY JEFF WILLIAMS, OWASP CHAIR

Many organizations have realized that their code is not as secure as they may have thought. Now
they're starting the difficult work of verifying the security of their applications.

There are four basic techniques for analyzing the security of a software application - automated
scanning, manual penetration testing, static analysis, and manual code review. This OWASP Guide is
focused on the last of these techniques. Of course, all of these techniques have their strengths,
weaknesses, sweet spots, and blind spots. Arguments about which technique is the best are like arguing
whether a hammer or saw is more valuable when building a house. If you try to build a house with just a
hammer, you'll do a terrible job. More important than the tool is probably the person holding the
hammer anyway.

The OWASP guides are intended to teach you how to use these techniques. But the fact that they are
separate shouldn't be an indicator that they should be used alone. The Development Guide shows your
project how to architect and build a secure application, this Code Review Guide tells you how to verify
the security of your application's source code, and the Testing Guide shows you how to verify the
security of your running application.

Security moves too fast for traditional books to be of much use. But OWASP's collaborative environment
allows us to keep up to date. There are hundreds of contributors to the OWASP Guides, and we make
over a thousand updates to our materials every month. We're committed to making high quality
application security materials available to everyone. It's the only way we'll ever make any real progress
on application security as a software community.

Why Code Review?

I've been performing security code reviews (along with the other techniques) since 1998, and I've found
thousands of serious vulnerabilities. In my experience, design documentation, code comments, and
even developers themselves are often misleading. The code doesn't lie. Actually, the code is your only
advantage over the hackers. Don't give up this advantage and rely only on external penetration testing.
Use the code.

Despite the many claims that code review is too expensive or time consuming, there is no question that
it is the fastest and most accurate way to find and diagnose many security problems. There are also
dozens of serious security problems that simply can't be found any other way. I can't emphasize the
cost-effectiveness of security code review enough. Consider which of the approaches will identify the
largest amount of the most significant security issues in your application, and security code review
quickly becomes the obvious choice. This applies no matter what amount of money you can apply to
the challenge.

Every application is different; that's why I believe it's important to empower the individuals verifying
security to use the most cost-effective techniques available. One common pattern is to use security
code review to find a problem, and penetration testing to prove that it is exploitable. Another pattern is
finding a potential issue with penetration testing, and then verifying the issue by finding and examining
the code. I strongly believe that the "combined" approach is the best choice for most applications.

4
 OWASP Code Review Guide V1.1 2008

Getting Started

It's important to recognize that code is a rich expressive language that can be used to build anything.
Analyzing arbitrary code is a difficult job that requires a lot of context. It's a lot like searching a legal
contract for loopholes. So while it may seem tempting to rely on an automated tool that simply finds
security holes, it's important to realize that these tools are more like spell-checkers or grammar-checkers.
While important, they don't understand the context, and miss many important security issues. Still,
running tools is a great way to gather data that you can use in your code review.

All you need to get started is a copy of the software baseline, a modern IDE, and the ability to think
about the ways security holes get created. I strongly recommend that before you look at any code, you
think hard about what is most important to your application. Then you verify that the security
mechanisms are present, free from flaws, and properly used. You'll trace through the control and data
flows in the application, thinking about what might go wrong.

Call to Action

If you're building software, I strongly encourage you to get familiar with the security guidance in this
document. If you find errors, please add a note to the discussion page or make the change yourself.
You'll be helping thousands of others who use this guide.

Please consider joining us as an individual or corporate member so that we can continue to produce
materials like this code review guide and all the other great projects at OWASP.

Thank you to all the past and future contributors to this guide, your work will help to make applications
worldwide more secure.

-- Jeff Williams, OWASP Chair, October 17, 2007

5
 OWASP Code Review Guide V1.1 2008

WELCOME TO THE OWASP CODE REVIEW GUIDE 1.1

“my children, the internet is broken, can we fix this mess?”

-- Eoin Keary, OWASP Code Review Guide Lead Author & Editor

OWASP thanks the authors, reviewers, and editors for their hard work in bringing this guide to where it is
today. If you have any comments or suggestions on the Code review Guide, please e-mail the Code
review Guide mail list:

https://lists.owasp.org/mailman/listinfo/owasp-codereview

COPYRIGHT AND LICENSE

Copyright (c) 2008 The OWASP Foundation.

This document is released under the Creative Commons Attribution Share Alike 3.0 license. Please read
and understand the license and copyright conditions.

REVISION HISTORY

The Code review guide originated in 2006 and as a splinter project from the testing guide. It was
conceived by Eoin Keary in 2005 and transformed into a wiki.

September 30, 2007

"OWASP Code Review Guide", Version 1.0 (RC1)

December 22, 2007

"OWASP Code Review Guide", Version 1.0 (RC2)

November 01, 2008

"OWASP Code Review Guide", Version 1.1 (Release)

EDITORS

Eoin Keary: OWASP Code Review Guide 2005 - Present

AUTHORS
Andrew van der Stock Dinis Cruz Jenelle Chapman
David Lowery Eoin Keary Marco M. Morana
David Rook Jeff Williams Paulo Prego

REVIEWERS

6
 OWASP Code Review Guide V1.1 2008

Jeff Williams P.Satish Kumar Rahim Jina

TRADEMARKS

• Java, Java EE, Java Web Server, and JSP are registered trademarks of Sun Microsystems, Inc.

• Microsoft is a registered trademark of Microsoft Corporation.

• OWASP is a registered trademark of the OWASP Foundation

All other products and company names may be trademarks of their respective owners. Use of a term in
this document should not be regarded as affecting the validity of any trademark or service mark.

SUMMER OF CODE 2008

The Code review guide is proudly sponsored by the OWASP Summer of Code (SoC) 2008. For more
information please see https://www.owasp.org/index.php/OWASP_Summer_of_Code_2008

PROJECT CONTRIBUTORS

The OWASP Code Review project was conceived by Eoin Keary the OWASP Ireland Founder and
Chapter Lead. We are actively seeking individuals to add new sections as new web technologies
emerge. If you are interested in volunteering for the project, or have a comment, question, or
suggestion, please drop me a line mailto:[email protected]

JOIN THE CODE REVIEW GUIDE TEAM

All of the OWASP Guides are living documents that will continue to change as the threat and security
landscape changes.

We welcome everyone to join the Code Review Guide Project and help us make this document great.
The best way to get started is to subscribe to the mailing list by following the link below. Please
introduce yourself and ask to see if there is anything you can help with. We are always looking for new
contributions. If there is a topic that you’d like to research and contribute, please let us know!

http://lists.owasp.org/mailman/listinfo/owasp-codereview

7
 OWASP Code Review Guide V1.1 2008

ABOUT THE OPEN WEB APPLICATION SECURITY PROJECT

The Open Web Application Security Project (OWASP) is an open community dedicated to enabling
organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP
tools, documents, forums, and chapters are free and open to anyone interested in improving
application security. We advocate approaching application security as a people, process, and
technology problem because the most effective approaches to application security include
improvements in all of these areas. We can be found at http://www.owasp.org.

OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide
unbiased, practical, cost-effective information about application security. OWASP is not affiliated with
any technology company, although we support the informed use of commercial security technology.
Similar to many open-source software projects, OWASP produces many types of materials in a
collaborative, open way. The OWASP Foundation is a not-for-profit entity that ensures the project's long-
term success. For more information, please see the pages listed below:

• Contact for information about communicating with OWASP

• Contributions for details about how to make contributions

• Advertising if you're interested in advertising on the OWASP site

• How OWASP Works for more information about projects and governance

• OWASP brand usage rules for information about using the OWASP brand

STRUCTURE

The OWASP Foundation is the not-for-profit (501c3) entity that provides the infrastructure for the OWASP
community. The Foundation provides support for our worldwide projects, chapters, and conferences
and manages our servers and bandwidth.

LICENSING

The OWASP Code Review Guide is available under the Creative Commons Share-Alike 3.0 Attribution
license. This license allows us to ensure that this knowledge remains free and open while encouraging
contribution and authorship.

All OWASP materials are available under an approved open source license. If you opt to become an
OWASP member organization, you can also use the commercial license that allows you to use, modify,
and distribute all OWASP materials within your organization under a single license.

For more information, please see the OWASP Licenses page.

PARTICIPATION AND MEMBERSHIP

8
 OWASP Code Review Guide V1.1 2008

Everyone is welcome to participate in our forums, projects, chapters, and conferences. OWASP is a
fantastic place to learn about application security, to network, and even to build your reputation as an
expert.

If you find the OWASP materials valuable, please consider supporting our cause by becoming an
OWASP member. All monies received by the OWASP Foundation go directly into supporting OWASP
projects.

For more information, please see the Membership page.

PROJECTS

OWASP's projects cover many aspects of application security. We build documents, tools, teaching
environments, guidelines, checklists, and other materials to help organizations improve their capability
to produce secure code.

For details on all the OWASP projects, please see the OWASP Project page.

OWASP PRIVACY POLICY

Given OWASP’s mission to help organizations with application security, you have the right to expect
protection of any personal information that we might collect about our members.

In general, we do not require authentication or ask visitors to reveal personal information when visiting
our website. We collect Internet addresses, not the e-mail addresses, of visitors solely for use in
calculating various website statistics.

We may ask for certain personal information, including name and email address from persons
downloading OWASP products. This information is not divulged to any third party and is used only for the
purposes of:

• Communicating urgent fixes in the OWASP Materials

• Seeking advice and feedback about OWASP Materials

• Inviting participation in OWASP’s consensus process and AppSec conferences

OWASP publishes a list of member organizations and individual members. Listing is purely voluntary and
“opt-in”. Listed members can request not to be listed at any time.

All information about you or your organization that you send us by fax or mail is physically protected. If
you have any questions or concerns about our privacy policy, please contact us at [email protected]

9
 OWASP Code Review Guide V1.1 2008

CODE REVIEW GUIDE HISTORY

The Code Review guide is the result of initially contributing and leading the Testing Guide. Initially it was
thought to place Code review and testing into the same guide; it seemed like a good idea at the time.
But the topic called security code review got too big and evolved into its own stand-alone guide.

The Code Review guide was started in 2006. The Code Review team consists of a small, but talented,
group of volunteers who should really get out more often.

The team noticed that organizations with a proper code review function integrated into the software
development lifecycle (SDLC) produced remarkably better code from a security standpoint. This
observation has borne out in practice, as many security vulnerabilities are easier to find in the code
than by using other techniques.

By necessity, this guide does not cover all languages; it mainly focuses on .NET and Java, but has a little
C/C++ and PHP thrown in also. However, the techniques advocated in the book can be easily adapted
to almost any code environment. Fortunately, the security flaws in web applications are remarkably
consistent across programming languages.

10
 OWASP Code Review Guide V1.1 2008

INTRODUCTION

Code review is probably the single-most effective technique for identifying security flaws. When used
together with automated tools and manual penetration testing, code review can significantly increase
the cost effectiveness of an application security verification effort.

This document does not prescribe a process for performing a security code review. Rather, this guide
focuses on the mechanics of reviewing code for certain vulnerabilities, and provides limited guidance
on how the effort should be structured and executed. OWASP intends to develop a more detailed
process in a future version of this guide.

Manual security code review provides insight into the “real risk” associated with insecure code. This is
the single most important value from a manual approach. A human reviewer can understand the
context for certain coding practices, and make a serious risk estimate that accounts for both the
likelihood of attack and the business impact of a breach.

WHY DOES CODE HAVE VULNERABILITIES?

MITRE has catalogued almost 700 different kinds of software weaknesses in their CWE project. These are
all different ways that software developers can make mistakes that lead to insecurity. Every one of these
weaknesses is subtle and many are seriously tricky. Software developers are not taught about these
weaknesses in school and most do not receive any training on the job about these problems.

These problems have become so important in recent years because we continue to increase
connectivity and to add technologies and protocols at a shocking rate. Our ability to invent technology
has seriously outstripped our ability to secure it. Many of the technologies in use today simply have not
received any security scrutiny.

There are many reasons why businesses are not spending the appropriate amount of time on security.
Ultimately, these reasons stem from an underlying problem in the software market. Because software is
essentially a black-box, it is extremely difficult to tell the difference between good code and insecure
code. Without this visibility, buyers won’t pay more for secure code, and vendors would be foolish to
spend extra effort to produce secure code.

One goal for this project is to help software buyers gain visibility into the security of software and start to
effect change in the software market.

Nevertheless, we still frequently get pushback when we advocate for security code review. Here are
some of the (unjustified) excuses that we hear for not putting more effort into security:

“We never get hacked (that I know of), we don’t need security”

“We have a firewall that protects our applications”

"We trust our employees not to attack our applications"

Over the last 10 years, the team involved with the OWASP Code Review Project have performed
thousands of application reviews, and found that every single application has had serious vulnerabilities.

11
 OWASP Code Review Guide V1.1 2008

If you haven’t reviewed your code for security holes the likelihood that your application has problems is
virtually 100%.

Still, there are many organizations that choose not to know about the security of their code. To them,
we offer Rumsfeld’s cryptic explanation of what we actually know. If you’re making informed decisions
to take risk in your enterprise, we fully support you. However, if you don’t even know what risks you are
taking, you are being irresponsible both to your shareholders and your customers.

"...we know, there are known knowns; there are things we know we know. We also know there are
known unknowns; that is to say we know there are some things we do not know. But there are also
unknown unknowns -- the ones we don't know we don't know." - Donald Rumsfeld

WHAT IS SECURITY CODE REVIEW?

Security code review is the process of auditing the source code for an application to verify that the
proper security controls are present, that they work as intended, and that they have been invoked in all
the right places. Code review is a way of ensuring that the application has been developed so as to be
“self-defending” in its given environment.

Security code review is a method of assuring secure application developers are following secure
development techniques. A general rule of thumb is that a penetration test should not discover any
additional application vulnerabilities relating to the developed code after the application has
undergone a proper security code review.

All security code reviews are a combination of human effort and technology support. At one end of the
spectrum is an inexperienced person with a text editor. At the other end of the scale is a security expert
with an advanced static analysis tool. Unfortunately, it takes a fairly serious level of expertise to use the
current application security tools effectively.

Tools can be used to perform this task but they always need human verification. Tools do not
understand context, which is the keystone of security code review. Tools are good at assessing large
amounts of code and pointing out possible issues but a person needs to verify every single result to
determine if it is a real issue, if it is actually exploitable, and calculate the risk to the enterprise.

Human reviewers are also necessary to fill in for the significant blind spots where automated tools simply
cannot check.

12
 OWASP Code Review Guide V1.1 2008

PREPARATION

LAYING THE GROUND WORK

In order to effectively review a code baseline, it is critical that the review team understands the business
purpose of the application and the most critical business impacts. This will guide them in their search for
serious vulnerabilities. The team should also identify the different threat agents, their motivation, and
how they could potentially attack the application.

All this information can be assembled into a high-level threat model of the application that represents
all of information that is relevant to application security. The goal for the reviewer is to verify that the key
risks have been properly addressed by security controls that work properly and are used in all the right
places.

Ideally the reviewer should be involved in the design phase of the application, but this is almost never
the case. More likely, the review team will be presented with a large codebase, say 450,000 lines of
code, and will need to get organized and make the best possible use of the time available.

Performing code review can feel like an audit, and most developers hate being audited. The way to
approach this is to create an atmosphere of collaboration between the reviewer, the development
team, the business representatives, and any other vested interests. Portraying the image of an advisor
and not a policeman is very important if you wish to get full co-operation from the development team.

Security code review teams that successfully build trust with the development team can become
trusted advisor. In many cases, this will lead to getting security folks involved earlier in the lifecycle, and
can significantly cut down on security costs.

BEFORE WE START:

The reviewer(s) need to be familiar with:

1. Code: The language(s) used, the features and issues of that language from a security
perspective. The issues one needs to look out for and best practices from a security and
performance perspective.

2. Context: The working of the application being reviewed. All security is in context of what we are
trying to secure. Recommending military standard security mechanisms on an application that
vends apples would be over-kill, and out of context. What type of data is being manipulated or
processed and what would the damage to the company be if this data was compromised.
Context is the “Holy Grail” of secure code inspection and risk assessment…we’ll see more later.

3. Audience: The intended users of the application, is it externally facing or internal to “trusted”
users. Does this application talk to other entities (machines/services)? Do humans use this
application?

4. Importance: The availability of the application is also important. Shall the enterprise be affected
in any great way if the application is “bounced” or shut down for a significant or insignificant
amount of time?

13
 OWASP Code Review Guide V1.1 2008

DISCOVERY: GATHERING THE INFORMATION

The review team will need certain information about the application in order to be effective. The
information should be assembled into a threat model that can be used to prioritize the review.
Frequently, this information can be obtained by studying design documents, business requirements,
functional specifications, test results, and the like. However, in most real-world projects, the
documentation is significantly out of date and almost never has appropriate security information.

Therefore, one of the most effective ways to get started, and arguably the most accurate, is to talk with
the developers and the lead architect for the application. This does not have to be a long meeting, but
just enough for the development team to share some basic information about the key security
considerations and controls. A walkthrough of the actual running application is very helpful, to give the
review team a good idea about how the application is intended to work. Also, a brief overview of the
structure of the codebase and any libraries used can help the review team get started.

If the information about the application cannot be gained in any other way, then the team will have to
spend some time doing reconnaissance and sharing information about how the application appears to
work by examining the code.

CONTEXT, CONTEXT, CONTEXT

Security code review is not simply about reviewing code. It’s important to remember that the reason
that we review code is to ensure that the code adequately protects the information and assets it has
been entrusted with, such as money, intellectual property, trade secrets, lives, or data.

The context in which the application is intended to operate is a very important issue in establishing
potential risk. If reviewers do not understand the business context, they will not be able to find the most
important risks and may focus on issues that are inconsequential to the business.

As preparation for a security code review, a high level threat model should be prepared which includes
the relevant information. This process is described more fully in a later section, but the major areas are
listed here:

• Threat Agents
• Attack Surface (including any public and backend interfaces)
• Possible Attacks
• Required Security Controls (both to stop likely attacks and to meet corporate policy)
• Potential Technical Impacts
• Important Business Impacts

Defining context should provide us with the following information:

• Establish the importance of application to enterprise.
• Establish the boundaries of the application context.
• Establish the trust relationships between entities.

14
 OWASP Code Review Guide V1.1 2008

• Establish potential threats and possible controls.

The review team can use simple questions like the following to gather this information from the
development team:

“What type/how sensitive is the data/asset contained in the application?”:

This is a keystone to security and assessing possible risk to the application. How desirable is the
information? What effect would it have on the enterprise if the information were compromised in any
way?

“Is the application internal or external facing?”, “Who uses the application; are they trusted users?”

This is a bit of a false sense of security as attacks take place by internal/trusted users more often than is
acknowledged. It does give us context that the application should be limited to a finite number of
identified users, but it’s not a guarantee that these users shall all behave properly.

“Where does the application host sit?”

Users should not be allowed past the DMZ into the LAN without being authenticated. Internal users also
need to be authenticated. No authentication = no accountability and a weak audit trail.

If there are internal and external users, what are the differences from a security standpoint? How do we
identify one from another? How does authorization work?

“How important is this application to the enterprise?”

Is the application of minor significance or a Tier A / Mission critical application, without which the
enterprise would fail? Any good web application development policy would have additional
requirements for different applications of differing importance to the enterprise. It would be the
analyst’s job to ensure the policy was followed from a code perspective also.

A useful approach is to present the team with a checklist, which asks the relevant questions pertaining
to any web application.

THE CHECKLIST

Defining a generic checklist which can be filled out by the development team is of high value, if the
checklist asks the correct questions in order to give us context. The checklist is a good barometer for the
level of security the developers have attempted or thought of. The checklist should cover the most
critical security controls and vulnerability areas such as:

• Data Validation

• Authentication

• Session management

• Authorization

• Cryptography

15
 OWASP Code Review Guide V1.1 2008

• Error handling

• Logging

• Security Configuration

• Network Architecture

16
 OWASP Code Review Guide V1.1 2008

SECURITY CODE REVIEW IN THE SDLC

Security code reviews vary widely in their level of formality. Reviews can be as informal as inviting a
friend to help look for a hard to find vulnerability, and they can be as formal as a software inspection
process with trained teams, assigned roles and responsibilities, and a formal metric and quality tracking
program.

In Peer Reviews in Software, Karl Wiegers lists seven review processes from least to most formal:

1. Ad hoc review
2. Passaround
3. Pair programming
4. Walkthrough
5. Team review
6. Inspection

Throughout the SDLC there are points at which an application security consultant should get involved.
Performing security activities across the lifecycle has proven to be far more cost-effective than either a
“big design up front” security effort or a single pre-production security review. The reason for
intervening at regular intervals is that potential issues can be detected early on in the development life
cycle where they are less costly to address.

Integration of security code review into the System Development Life Cycle (SDLC) can yield dramatic
results to the overall quality of the code developed. Security code review is not a silver bullet, but is part
of a healthy application development diet. Consider it as one of the layers in a defense-in-depth
approach to application security. Security code review is also a cornerstone of the approach to
developing secure software. The idea of integrating a phase into your SLDC may sound daunting, yet
another layer of complexity or an additional cost, but in the long term and in today's cyber landscape it
is cost effective, reputation building, and in the best interest of any business to do so.

Waterfall SDLC Example

1. Requirements definition
1. Application Security Requirements
2. Architecture and Design
1. Application Security Architecture and/or Threat Model
3. Development
1. Secure Coding Practices
2. Security Testing
3. Security Code Review
4. Test
1. Penetration Testing
5. Deployment
1. Secure Configuration Management
2. Secure Deployment
6. Maintenance

17
 OWASP Code Review Guide V1.1 2008

Agile Security Methodology Example

1. Planning
1. Identify Security Stakeholder Stories
2. Identify Security Controls
3. Identify Security Test Cases
2. Sprints
1. Secure Coding
2. Security Test Cases
3. Peer Review with Security
3. Deployment
1. Security Verification (with Penetration Testing and Security Code Review)

18
 OWASP Code Review Guide V1.1 2008

SECURITY CODE REVIEW COVERAGE

UNDERSTANDING THE ATTACK SURFACE

“For every input there will be an equal and opposite output (Well sort of)”

A major part of actually performing a security code review is performing an analysis of the attack
surface. An application takes inputs and produces output of some kind. Attacking applications is
down to using the streams for input and trying to sail a battleship up them that the application is not
expecting. Firstly, all input to the code needs to be identified. Input, for example, can be:

• Browser input
• Cookies
• Property files
• External processes
• Data feeds
• Service responses
• Flat files
• Command line parameters
• Environment variables

Exploring the attack surface includes dynamic and static data flow analysis: Where and when are
variables set and how the variables are used throughout the workflow, how attributes of objects and
parameters might affect other data within the program. It determines if the parameters, method
calls, and data exchange mechanisms implement the required security.

19
 OWASP Code Review Guide V1.1 2008

All transactions within the application need to be identified and analyzed along with the relevant
security functions they invoke. The areas that are covered during transaction analysis are:

• Data/Input Validation of data from all untrusted sources.

• Authentication
• Session Management
• Authorization
• Cryptography (Data at rest and in transit)
• Error Handling /Information Leakage
• Logging /Auditing
• Secure Code Environment

UNDERSTAND WHAT YOU ARE REVIEWING:

Many modern applications are developed on frameworks. These frameworks provide the developer
less work to do as the framework does much of the “Housekeeping”. So the objects developed by
the development team shall extend the functionality of the framework. It is here that the knowledge
of a given framework, and language in which the framework and application is implemented, is of
paramount importance. Much of the transactional functionality may not be visible in the
developer’s code and handled in “Parent” classes.

The analyst must be aware and knowledgeable of the underlying framework.

For example:

Java:

In struts the struts-config.xml and the web.xml files are the core points to view the transactional
functionality of an application.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.0//EN"
"http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd">
<struts-config>
<form-beans>
<form-bean name="login" type="test.struts.LoginForm" />
</form-beans>
<global-forwards>
</global-forwards>
<action-mappings>
<action
path="/login"
type="test.struts.LoginAction" >

20
 OWASP Code Review Guide V1.1 2008

<forward name="valid" path="/jsp/MainMenu.jsp" /> <forward name="invalid"

path="/jsp/LoginView.jsp" /> </action>
</action-mappings>
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property property="pathnames"
value="/test/WEB-INF/validator-rules.xml, /WEB-INF/validation.xml"/>
</plug-in>
</struts-config>

The struts-config.xml file contains the action mappings for each HTTP request while the web.xml file
contains the deployment descriptor.

Example: The struts framework has a validator engine, which relies on regular expressions to validate
the input data. The beauty of the validator is that no code has to be written for each form bean.
(Form bean is the java object which received the data from the HTTP request). The validator is not
enabled by default in struts. To enable, the validator a plug-in must be defined in the <plug-in>
section of struts-config.xml in Red above. The property defined tells the struts framework where the
custom validation rules are defined (validation.xml) and a definition of the actual rules themselves
(validation-rules.xml).

Without a proper understanding of the struts framework, and by simply auditing the java code, one
would net see any validation being executed, and one does not see the relationship between the
defined rules and the java functions.

The action mappings in Blue define the action taken by the application upon receiving a request.
Here, above we can see that when the URL contains /login the LoginAction shall be called. From the
action mappings we can see the transactions the application performs when external input is
received.

.NET:

ASP.NET/ IIS applications use an optional XML-based configuration file named web.config, to
maintain application configuration settings. This covers issues such as authentication, authorization,
Error pages, HTTP settings, debug settings, web service settings etc..

Without knowledge of these files a transactional analysis would be very difficult and not accurate.

Optionally, you may provide a file web.config at the root of the virtual directory for a Web
application. If the file is absent, the default configuration settings in machine.config will be used. If
the file is present, any settings in web.config will override the default settings.

Example of the web.config file:

<authentication mode="Forms">
<forms name="name"
loginUrl="url"
protection="Encryption"

21
 OWASP Code Review Guide V1.1 2008

timeout="30" path="/" >

requireSSL="true|"
slidingExpiration="false">
<credentials passwordFormat="Clear">
<user name="username" password="password"/>
</credentials>
</forms>
<passport redirectUrl="internal"/>
</authentication>

From this config file snippet we can see that:

authentication mode: The default authentication mode is ASP.NET forms-based authentication.

loginUrl: Specifies the URL where the request is redirected for logon if no valid authentication cookie
is found.

protection: Specifies that the cookie is encrypted using 3DES or DES but DV is not performed on the
cookie. Beware of plaintext attacks!!

timeout: Cookie expiry time in minutes

The point to make here is that many of the important security settings are not set in the code per se,
but in the framework configuration files. Knowledge of the framework is of paramount importance
when reviewing framework-based applications.

22
 OWASP Code Review Guide V1.1 2008

APPLICATION THREAT MODELING

INTRODUCTION

Threat modeling is an approach for analyzing the security of an application. It is a structured

approach that enables you to identify, quantify, and address the security risks associated with an
application. Threat modeling is not an approach to reviewing code but it does complement the
security code review process. The inclusion of threat modeling in the SDLC can help to ensure that
applications are being developed with security built-in from the very beginning. This, combined with
the documentation produced as part of the threat modeling process, can give the reviewer a
greater understanding of the system. This allows the reviewer to see where the entry points to the
application are and the associated threats with each entry point. The concept of threat modeling is
not new but there has been a clear mindset change in recent years. Modern threat modeling looks
at a system from a potential attacker's perspective, as opposed to a defender's view point.
Microsoft have been strong advocates of the process over the past number of years. They have
made threat modeling a core component of their SDLC which they claim to be one of the reasons
for the increased security of their products in recent years.

When source code analysis is performed outside the SDLC such as on existing applications, the
results of the threat modeling help in reducing the complexity of the source code analysis by
promoting an in-depth first approach vs. breadth first approach. Instead of reviewing all source
code with equal focus, you can prioritize the security code review of components whose threat
modeling has ranked with high risk threats.

The threat modeling process can be decomposed into 3 high level steps:

Step 1: Decompose the Application. The first step in the threat modeling process is concerned with
gaining an understanding of the application and how it interacts with external entities. This involves
creating use-cases to understand how the application is used, identifying entry points to see where
a potential attacker could interact with the application, identifying assets i.e. items/areas that the
attacker would be interested in, and identifying trust levels which represent the access rights that
the application will grant to external entities. This information is documented in the Threat Model
document and it is also used to produce data flow diagrams (DFDs) for the application. The DFDs
show the different paths through the system, highlighting the privilege boundaries.

Step 2: Determine and rank threats. Critical to the identification of threats is using a threat
categorization methodology. A threat categorization such as STRIDE can be used, or the
Application Security Frame (ASF) that defines threat categories such as Auditing & Logging,
Authentication, Authorization, Configuration Management, Data Protection in Storage and Transit,
Data Validation, Exception Management. The goal of the threat categorization is help identify
threats both from the attacker (STRIDE) and the defensive perspective (ASF). DFDs produced in step
1 help to identify the potential threat targets from the attacker's perspective, such as data sources,
processes, data flows, and interactions with users. These threats can be identified further as the roots
for threat trees; there is one tree for threat goal. From the defensive perspective, ASF categorization
helps to identify the threats as weaknesses of security controls for such threats. Common threat-lists
with examples can help in the identification of such threats. Use and abuse cases can illustrate how
existing protective measures could be bypassed, or where a lack of such protection exists. The

23
 OWASP Code Review Guide V1.1 2008

determination of the security risk for each threat can be determined using a value based risk model
such as DREAD or a less subjective qualitative risk model based upon general risk factors (e.g.
likelihood and impact).

Step 3: Determine countermeasures and mitigation. A lack of protection of a threat might indicate a
vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure.
Such countermeasures can be identified using threat-countermeasure mapping lists. Once a risk
ranking is assigned to the threats, it is possible to sort threats from the highest to the lowest risk, and
prioritize the mitigation effort, such as by responding to such threats by applying the identified
countermeasures. The risk mitigation strategy might involve evaluating these threats from the
business impact that they pose and reducing the risk. Other options might include taking the risk,
assuming the business impact is acceptable because of compensating controls, informing the user
of the threat, removing the risk posed by the threat completely, or the least preferable option, that is,
to do nothing.

Each of the above steps are documented as they are carried out. The resulting document is the
threat model for the application. This guide will use an example to help explain the concepts behind
threat modeling. The same example will be used throughout each of the 3 steps as a learning aid.
The example that will be used is a college library website. At the end of the guide we will have
produced the threat model for the college library website. Each of the steps in the threat modeling
process are described in detail below.

DECOMPOSE THE APPLICATION

The goal of this step is to gain an understanding of the application and how it interacts with external
entities. This goal is achieved by information gathering and documentation. The information
gathering process is carried out using a clearly defined structure, which ensures the correct
information is collected. This structure also defines how the information should be documented to
produce the Threat Model.

THREAT MODEL INFORMATION

The first item in the threat model is the information relating to the threat model. This must include the
the following:

1. Application Name - The name of the application.

2. Application Version - The version of the application.
3. Description - A high level description of the application.
4. Document Owner - The owner of the threat modeling document.
5. Participants - The participants involved in the threat modeling process for this application.
6. Reviewer - The reviewer(s) of the threat model.

Example:

24
 OWASP Code Review Guide V1.1 2008

<Application Name>Threat Model Information

Application
1.0
Version:

The college library website is the first implementation of a website to provide librarians and
library patrons (students and college staff) with online services.

As this is the first implementation of the website, the functionality will be limited. There will be
three users of the application:
Description: 1. Students
2. Staff
3. Librarians
Staff and students will be able to log in and search for books, and staff members can request
books. Librarians will be able to log in, add books, add users, and search for books.

Document
David Lowry
Owner:

Participants: David Rook

Reviewer: Eoin Keary

EXTERNAL DEPENDENCIES

External dependencies are items external to the code of the application that may pose a threat to
the application. These items are typically still within the control of the organization, but possibly not
within the control of the development team. The first area to look at when investigating external
dependencies is how the application will be deployed in a production environment and what are
the requirements surrounding this. This involves looking at how the application is or is not intended to
be run. For example if the application is expected to be run on a server that has been hardened to
the organization's hardening standard and it is expected to sit behind a firewall, then this
information should be documented in the external dependencies section. External dependencies
should be documented as follows:

1. ID - A unique ID assigned to the external dependency.

2. Description - A textual description of the external dependency.

25
 OWASP Code Review Guide V1.1 2008

Example:

External Dependencies

ID Description

The college library website will run on a Linux server running Apache. This server will be hardened as per the
1 college's server hardening standard. This includes the application of the latest operating system and
application security patches.

The database server will be MySQL and it will run on a Linux server. This server will be hardened as per the
2 college's server hardening standard. This will include the application of the latest operating system and
application security patches.

3 The connection between the Web Server and the database server will be over a private network.

4 The Web Server is behind a firewall and the only communication available is TLS

ENTRY POINTS

Entry points define the interfaces through which potential attackers can interact with the
application or supply it with data. In order for potential attacker to attack an application, entry
points must exist. Entry points in an application can be layered, for example each web page in a
web application may contain multiple entry points. Entry points should be documented as follows:

1. ID - A unique ID assigned to the entry point. This will be used to cross reference the entry point
with any threats or vulnerabilities that are identified. In the case of layer entry points a
major.minor notation should be used.
2. Name - A descriptive name identifying the entry point and its purpose.
3. Description - A textual description detailing the interaction or processing that occurs at the entry
point.
4. Trust Levels - The level of access required at the entry point is documented here. These will be
cross referenced with the trusts levels defined later in the document.

Example:

Entry Points

ID Name Description Trust Levels

(1) Anonymous Web

User
The college library website will be only be
accessable via TLS. All pages within the
1 HTTPS Port (2) User with Valid
college library website are layered on this
Login Credentials
entry point.
(3) User with Invalid
Login Credentials

26
 OWASP Code Review Guide V1.1 2008

(4) Librarian

(1) Anonymous Web

User
Library
The splash page for the college library (2) User with Valid
1.1 Main
website is the entry point for all users. Login Credentials
Page
(3) User with Invalid
Login Credentials
(4) Librarian

(1) Anonymous Web

User
Students, faculty members and librarians
Login must login to the college library website (2) User with Login
1.2
Page before they can carry out any of the use Credentials
cases. (3) User with Invalid
Login Credentials
(4) Librarian

(2) User with Valid

Login Credentials
The login function accepts user supplied
Login (3) User with Invalid
1.2.1 credentials and compares them with those in
Function Login Credentials
the database.
(4) Librarian

(2) User with Valid

Search
Login Credentials
1.3 Entry The page used to enter a search query.
Page
(4) Librarian

ASSETS

The system must have something that the attacker is interested in; these items/areas of interest are
defined as assets. Assets are essentially threat targets, i.e. they are the reason threats will exist. Assets
can be both physical assets and abstract assets. For example, an asset of an application might be a
list of clients and their personal information; this is a physical asset. An abstract asset might be the
reputation of an organsation. Assets are documented in the threat model as follows:

1. ID - A unique ID is assigned to identify each asset. This will be used to cross reference the asset
with any threats or vulnerabilities that are identified.
2. Name - A descriptive name that clearly identifies the asset.
3. Description - A textual description of what the asset is and why it needs to be protected.
4. Trust Levels - The level of access required to access the entry point is documented here. These
will be cross referenced with the trust levels defined in the next step.

27
 OWASP Code Review Guide V1.1 2008

Example:

Assets

ID Name Description Trust Levels

Library
Assets relating to students, faculty members and
1 Users and
librarians.
Librarian

(2) User with Valid

Login Credentials
(4) Librarian
(5) Database
Server
The login credentials that a student or a faculty
User Login Administrator
1.1 member will use to log into the College Library
Details (7) Web Server
website.
User Process
(8) Database
Read User
(9) Database
Read/Write User

(4) Librarian
(5) Database
Server
Administrator
Librarian
The login credentials that a Librarian will use to log (7) Web Server
1.2 Login
into the College Library website. User Process
Details
(8) Database
Read User
(9) Database
Read/Write User

(4) Librarian
(5) Database
Server
Administrator
(6) Website
The College Library website will store personal
Personal Administrator
1.3 information relating to the students, faculty
Data (7) Web Server
members and librarians.
User Process
(8) Database
Read User
(9) Database
Read/Write User

2 System Assets relating to the underlying system.

Availability The College Library website should be available (5) Database

2.1
of College 24 hours a day and can be accessed by all Server

28
 OWASP Code Review Guide V1.1 2008

Library students, college faculty members and librarians. Administrator

Website (6) Website
Administrator

Ability to
Execute (6) Website
Code as a This is the ability to execute source code on the Administrator
2.2
Web web server as a web server user. (7) Web Server
Server User Process
User

(5) Database
Ability to Server
Execute This is the ability to execute SQL. Select queries on Administrator
2.3 SQL as a the database and thus retrieve any information (8) Database
Database stored within the College Library database. Read User
Read User (9) Database
Read/Write User

Ability to
(5) Database
Execute This is the ability to execute SQL. Select, insert, and
Server
SQL as a update queries on the database and thus have
2.4 Administrator
Database read and write access to any information stored
(9) Database
Read/Writ within the College Library database.
Read/Write User
e User

3 Website Assets relating to the College Library website.

This is the login session of a user to the College (2) User with Valid
Login
3.1 Library website. This user could be a student, a Login Credentials
Session
member of the college faculty, or a Librarian. (4) Librarian

Access to Access to the database server allows you to

(5) Database
the administer the database, giving you full access to
3.2 Server
Database the database users and all data contained within
Administrator
Server the database.

The ability to create users would allow an

Ability to (4) Librarian
individual to create new users on the system.
3.3 Create (6) Website
These could be student users, faculty member
Users Administrator
users, and librarian users.

Access to The audit data shows all audit-able events that

(6) Website
3.3 Audit occurred within the College Library application
Administrator
Data by students, staff, and librarians.

TRUST LEVELS

29
 OWASP Code Review Guide V1.1 2008

Trust levels represent the access rights that the application will grant to external entities. The trust
levels are cross referenced with the entry points and assets. This allows us to define the access rights
or privileges required at each entry point and those required to interact with each asset. Trust levels
are documented in the threat model as follows:

1. ID - A unique number is assigned to each trust level. This is used to cross reference the trust level
with the entry points and assets.
2. Name - A descriptive name that allows you to identify the external entities that have been
granted this trust level.
3. Description - A textual description of the trust level detailing the external entity who has been
granted the trust level.

Example:

Trust Levels

ID Name Description

Anonymous Web A user who has connected to the college library website but has
1
User not provided valid credentials.

User with Valid A user who has connected to the college library website and
2
Login Credentials has logged in using valid login credentials.

User with Invalid A user who has connected to the college library website and is
3
Login Credentials attempting to login in using invalid login credentials.

The librarian can create users on the library website and view
4 Librarian
their personal information.

Database Server The database server administrator has read and write access to
5
Administrator the database that is used by the college library website.

Website The Website administrator can configure the college library

6
Administrator website.

Web Server User This is the process/user that the web server executes code as
7
Process and authenticates itself against the database server as.

Database Read The database user account used to access the database for
8
User read access.

Database The database user account used to access the database for
9
Read/Write User read and write access.

DATA FLOW DIAGRAMS

30
 OWASP Code Review Guide V1.1 2008

All of the information collected allows us to accurately model the application through the use of Data
Flow Diagrams (DFDs). The DFDs will allow us to gain a better understanding of the application by
providing a visual representation of how the application processes data. The focus of the DFDs is on
how data moves through the application and what happens to the data as it moves. DFDs are
hierarchical in structure, so they can be used to decompose the application into subsystems and lower-
level subsystems. The high level DFD will allow us to clarify the scope of the application being modeled.
The lower level iterations will allow us to focus on the specific processes involved when processing
specific data. There are a number of symbols that are used in DFDs for threat modeling. These are
described below:

External Entity
The external entity shape is used to represent any entity outside the application that interacts with the
application via an entry point.

Process
The process shape represents a task that handles data within the application. The task may process the
data or perform an action based on the data.

Multiple Process
The multiple process shape is used to present a collection of subprocesses. The multiple process can be
broken down into its subprocesses in another DFD.

Data Store
The data store shape is used to represent locations where data is stored. Data stores do not modify the
data they only store data.

31
 OWASP Code Review Guide V1.1 2008

Data Flow
The data flow shape represents data movement within the application. The direction of the data
movement is represented by the arrow.

Privilege Boundary
The privilege boundary shape is used to represent the change of privilege levels as the data flows
through the application.

Example:
Data Flow Diagram for the College Library Website.

32
 OWASP Code Review Guide V1.1 2008

User Login Data Flow Diagram for the College Library Website.

DETERMINE AND RANK THREATS

THREAT CATEGORIZATION

The first step in the determination of threats is adopting a threat categorization. A threat categorization
provides a set of threat categories with corresponding examples so that threats can be systematically
identified in the application in a structured and repeatable manner.

STRIDE

A threat categorization such as STRIDE is useful in the identification of threats by classifying attacker
goals such as:

Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege.

33
 OWASP Code Review Guide V1.1 2008

A threat list of generic threats organized in these categories with examples and the affected security
controls is provided in the following table:

STRIDE Threat List

Security
Type Examples
Control

Threat action aimed to illegally access and use another user's

Spoofing Authentication
credentials, such as username and password

Threat action aimed to maliciously change/modify persistent

data, such as persistent data in a database, and the alteration of
Tampering Integrity
data in transit between two computers over an open network,
such as the Internet

Threat action aimed to perform illegal operation in a system that Non-

Repudiation
lacks the ability to trace the prohibited operations. Repudiation

Information Threat action to read a file that they were not granted access to,
Confidentiality
disclosure. or to read data in transit.

Denial of Threat aimed to deny access to valid users such as by making a

Availability
service. web server temporarily unavailable or unusable.

Elevation of Threat aimed to gain privileged access to resources for gaining

Authorization
privilege. unauthorized access to information or to compromise a system.

SECURITY CONTROLS

Once the basic threat agents and business impacts are understood, the review team should try to
identify the set of controls that could prevent these threat agents from causing those impacts. The
primary focus of the code review should be to ensure that these security controls are in place, that they
work properly, and that they are correctly invoked in all the necessary places. The checklist below can
help to ensure that all the likely risks have been considered.

Authentication:

• Ensure all internal and external connections (user and entity) go through an appropriate and
adequate form of authentication. Be assured that this control cannot be bypassed.
• Ensure all pages enforce the requirement for authentication.
• Ensure that whenever authentication credentials or any other sensitive information is passed,
only accept the information via the HTTP “POST” method and will not accept it via the HTTP
“GET” method.

34
 OWASP Code Review Guide V1.1 2008

• Any page deemed by the business or the development team as being outside the scope of
authentication should be reviewed in order to assess any possibility of security breach.
• Ensure that authentication credentials do not traverse the wire in clear text form.
• Ensure development/debug backdoors are not present in production code.

Authorization:

• Ensure that there are authorization mechanisms in place.

• Ensure that the application has clearly defined the user types and the rights of said users.
• Ensure there is a least privilege stance in operation.
• Ensure that the Authorization mechanisms work properly, fail securely, and cannot be
circumvented.
• Ensure that authorization is checked on every request.
• Ensure development/debug backdoors are not present in production code.

Cookie Management:

• Ensure that sensitive information is not comprised.

• Ensure that unauthorized activities cannot take place via cookie manipulation.
• Ensure that proper encryption is in use.
• Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure
manner.
• Determine if all state transitions in the application code properly check for the cookies and
enforce their use.
• Ensure the session data is being validated.
• Ensure cookie contains as little private information as possible.
• Ensure entire cookie should be encrypted if sensitive data is persisted in the cookie.
• Define all cookies being used by the application, their name and why they are needed.

Data/Input Validation:

• Ensure that a DV mechanism is present.

• Ensure all input that can (and will) be modified by a malicious user such as http headers, input
fields, hidden fields, drop down lists & other web components are properly validated.
• Ensure that the proper length checks on all input exist.
• Ensure that all fields, cookies, http headers/bodies & form fields are validated.
• Ensure that the data is well formed and contains only known good chars is possible.
• Ensure that the data validation occurs on the server side.
• Examine where data validation occurs and if a centralized model or decentralized model is
used.
• Ensure there are no backdoors in the data validation model.
• Golden Rule: All external input, no matter what it is, is examined and validated.

Error Handling/Information leakage:

• Ensure that all method/function calls that return a value have proper error handling and return
value checking.

35
 OWASP Code Review Guide V1.1 2008

• Ensure that exceptions and error conditions are properly handled.

• Ensure that no system errors can be returned to the user.
• Ensure that the application fails in a secure manner.
• Ensure resources are released if an error occurs.

Logging/Auditing:

• Ensure that no sensitive information is logged in the event of an error.

• Ensure the payload being logged is of a defined maximum length and that the logging
mechanism enforces that length.
• Ensure no sensitive data can be logged; E.g. cookies, HTTP “GET” method, authentication
credentials.
• Examine if the application will audit the actions being taken by the application on behalf of the
client (particularly data manipulation/Create, Update, Delete (CUD) operations).
• Ensure successful and unsuccessful authentication is logged.
• Ensure application errors are logged.
• Examine the application for debug logging with the view to logging of sensitive data.

Cryptography:

• Ensure no sensitive data is transmitted in the clear, internally or externally.

• Ensure the application is implementing known good cryptographic methods.

Secure Code Environment:

• Examine the file structure. Are any components that should not be directly accessible available
to the user?
• Examine all memory allocations/de-allocations.
• Examine the application for dynamic SQL and determine if it is vulnerable to injection.
• Examine the application for “main()” executable functions and debug harnesses/backdoors
• Search for commented out code, commented out test code, which may contain sensitive
information.
• Ensure all logical decisions have a default clause.
• Ensure no development environment kit is contained on the build directories.
• Search for any calls to the underlying operating system or file open calls and examine the error
possibilities.

Session management:

• Examine how and when a session is created for a user, unauthenticated and authenticated.

36
 OWASP Code Review Guide V1.1 2008

• Examine the session ID and verify if it is complex enough to fulfill requirements regarding strength.
• Examine how sessions are stored: e.g. in a database, in memory etc.
• Examine how the application tracks sessions.
• Determine the actions the application takes if an invalid session ID occurs.
• Examine session invalidation.
• Determine how multithreaded/multi-user session management is performed.
• Determine the session HTTP inactivity timeout.
• Determine how the log-out functionality functions.

THREAT ANALYSIS

The prerequisite in the analysis of threats is the understanding of the generic definition of risk that is the
probability that a threat agent will exploit a vulnerability to cause an impact to the application. From
the perspective of risk management, threat modeling is the systematic and strategic approach for
identifying and enumerating threats to an application environment with the objective of minimizing risk
and the associated impacts.

Threat analysis as such is the identification of the threats to the application, and involves the analysis of
each aspect of the application functionality and architecture and design to identify and classify
potential weaknesses that could lead to an exploit.

In the first threat modeling step, we have modeled the system showing data flows, trust boundaries,
process components, and entry and exit points. An example of such modeling is shown in the Example:
Data Flow Diagram for the College Library Website.

Data flows show how data flows logically through the end to end, and allows the identification of
affected components through critical points (i.e. data entering or leaving the system, storage of data)
and the flow of control through these components. Trust boundaries show any location where the level
of trust changes. Process components show where data is processed, such as web servers, application
servers, and database servers. Entry points show where data enters the system (i.e. input fields, methods)
and exit points are where it leaves the system (i.e. dynamic output, methods), respectively. Entry and
exit points define a trust boundary.

Threat lists based on the STRIDE model are useful in the identification of threats with regards to the
attacker goals. For example, if the threat scenario is attacking the login, would the attacker brute force
the password to break the authentication? If the threat scenario is to try to elevate privileges to gain
another user’s privileges, would the attacker try to perform forceful browsing?

It is vital that all possible attack vectors should be evaluated from the attacker’s point of view For this
reason, it is also important to consider entry and exit points, since they could also allow the realization of
certain kinds of threats. For example, the login page allows sending authentication credentials, and the
input data accepted by an entry point has to validate for potential malicious input to exploit
vulnerabilities such as SQL injection, cross site scripting and buffer overflows. Additionally, the data flow
passing through that point has to be used to determine the threats to the entry points to the next

37
 OWASP Code Review Guide V1.1 2008

components along the flow. If the following components can be regarded critical (e.g. the hold
sensitive data), that entry point can be regarded more critical as well. In an end to end data flow, for
example, the input data (i.e. username and password) from a login page, passed on without validation,
could be exploited for a SQL injection attack to manipulate a query for breaking the authentication or
to modify a table in the database.

Exit points might serve as attack points to the client (e.g. XSS vulnerabilities) as well for the realization of
information disclosure vulnerabilities. For example, in the case of exit points from components handling
confidential data (e.g. data access components), exit points lacking security controls to protect the
confidentiality and integrity can lead to disclosure of such confidential information to an unauthorized
user.

In many cases threats enabled by exit points are related to the threats of the corresponding entry point.
In the login example, error messages returned to the user via the exit point might allow for entry point
attacks, such as account harvesting (e.g. username not found), or SQL injection (e.g. SQL exception
errors).

From the defensive perspective, the identification of threats driven by security control categorization
such as ASF, allows a threat analyst to focus on specific issues related to weaknesses (e.g. vulnerabilities)
in security controls. Typically the process of threat identification involves going through iterative cycles
where initially all the possible threats in the threat list that apply to each component are evaluated.

At the next iteration, threats are further analyzed by exploring the attack paths, the root causes (e.g.
vulnerabilities, depicted as orange blocks) for the threat to be exploited, and the necessary mitigation
controls (e.g. countermeasures, depicted as green blocks). A threat tree as shown in figure 2 is useful to
perform such threat analysis

Once common threats, vulnerabilities, and attacks are assessed, a more focused threat analysis should
take in consideration use and abuse cases. By thoroughly analyzing the use scenarios, weaknesses can
be identified that could lead to the realization of a threat. Abuse cases should be identified as part of
the security requirement engineering activity. These abuse cases can illustrate how existing protective
measures could be bypassed, or where a lack of such protection exists. A use and misuse case graph
for authentication is shown in figure below:

38
 OWASP Code Review Guide V1.1 2008

Finally it is possible to bring all of this together by determining the types of threat to each component of
the decomposed system. This can be done by using a threat categorization such as STRIDE or ASF, the
use of threat trees to determine how the threat can be exposed by a vulnerability, and use and misuse
cases to further validate the lack of a countermeasure to mitigate the threat.

To apply STRIDE to the data flow diagram items the following table can be used:

39
 OWASP Code Review Guide V1.1 2008

RANKING OF THREATS

Threats can be ranked from the perspective of risk factors. By determining the risk factor posed by the
various identified threats, it is possible to create a prioritized list of threats to support a risk mitigation
strategy, such as deciding on which threats have to be mitigated first. Different risk factors can be used
to determine which threats can be ranked as High, Medium, or Low risk. In general, threat-risk models
use different factors to model risks such as those shown in figure below:

DREAD

In the Microsoft DREAD threat-risk ranking model, the technical risk factors for impact are Damage and
Affected Users, while the ease of exploitation factors are Reproducibility, Exploitability and
Discoverability. This risk factorization allows the assignment of values to the different influencing factors
of a threat. To determine the ranking of a threat the threat analyst has to answer basic questions for
each factor of risk, for example:

For Damage: How big the damage can be?

For Reproducibility: How easy is it to reproduce an attack to work?
For Exploitability: How much time, effort and expertise is needed to exploit the threat?
For Affected Users: If a threat were exploited, what percentage of users would be affected?
For Discoverability: How easy is it for an attacker to discover this threat?

40
 OWASP Code Review Guide V1.1 2008

By referring to the college library website it is possible to document sample threats releated to the use
cases such as:

Threat: Malicious user views confidential information of students, faculty members and librarians.

1. Damage potential: Threat to reputation as well as financial and legal liability:8

2. Reproducibility: Fully reproducible:10
3. Exploitability: Require to be on the same subnet or have compromised a router:7
4. Affected users: Affects all users:10
5. Discoverability: Can be found out easily:10

Overall DREAD score: (8+10+7+10+10) / 5 = 9

In this case, having 9 on a 10 point scale is certainly an high risk threat.

GENERIC RISK MODEL

A more generic risk model takes into consideration the Likelihood (e.g. probability of an attack) and the
Impact (e.g. damage potential):

Risk = Likelihood x Impact

The likelihood or probability is defined by the ease of exploitation, which mainly depends on the type of
threat and the system characteristics, and by the possibility to realize a threat, which is determined by
the existence of an appropriate countermeasure.

The following is a set of considerations for determining ease of exploitation:

1. Can an attacker exploit this remotely?

2. Does the attacker need to be authenticated?
3. Can the exploit be automated?

The impact mainly depends on the damage potential and the extent of the impact, such as the
number of components that are affected by a threat.

Examples to determine the damage potential are:

1. Can an attacker completely take over and manipulate the system?

2. Can an attacker gain administration access to the system?
3. Can an attacker crash the system?
4. Can the attacker obtain access to sensitive information such as secrets, PII ?

Examples to determine the number of components that are affected by a threat:

1. How many data sources and systems can be impacted?

2. How “deep” into the infrastructure can the threat agent go?

These examples help in the calculation of the overall risk values by assigning qualitative values such as
High, Medium and Low to Likelihood and Impact factors. In this case, using qualitative values, rather

41
 OWASP Code Review Guide V1.1 2008

than numeric ones like in the case of the DREAD model, help avoid the ranking becoming overly
subjective.

COUNTERMEASURE IDENTIFICATION

The purpose of the countermeasure identification is to determine if there is some kind of protective
measure (e.g. security control, policy measures) in place that can prevent each threat previosly
identified via threat analysis from being realized. Vulnerabilities are then those threats that have no
countermeasures. Since each of these threats has been categorized either with STRIDE or ASF, it is
possible to find appropriate countermeasures in the application within the given category.

Provided below is a brief and limited checklist which is by no means an exhaustive list for identifying
countermeasures for specific threats.

Example of countermeasures for ASF threat types are included in the following table:

ASF Threat & Countermeasures List

Threat Type Countermeasure

1. Credentials and
authentication tokens are
protected with encryption in
storage and transit
2. Protocols are resistant to
brute force, dictionary
attacks and replay attacks
3. Strong password policies are
enforced
4. Trusted server authentication
Authentication is used instead of SQL
authentication
5. Passwords are stored with
salted hashes
6. Password resets do not
reveal password hints and
valid usernames
7. Account lockouts do not
result in a denial of service
attack

1. Strong ACLs are used for

enforcing authorized access
Authorization to resources
2. Role-based access controls
are used to restrict access to

42
 OWASP Code Review Guide V1.1 2008

specific operations.
3. The system follows the
principle of least privilege for
user and service accounts
4. Privilege separation is
correctly configured within
the presentation, business
and data access layers.

1. Least privileged processes

are used and service
accounts with no
administration capability
2. Auditing and logging of all
Configuration Management administration activities is
enabled
3. Access to configuration files
and administrator interfaces
is restricted to administrators

1. Standard encryption
algorithms and correct key
sizes are being used
2. Hashed message
authentication codes
(HMACs) are used to protect
data integrity
3. Secrets (e.g. keys,
confidential data ) are
Data Protection in Storage and Transit
cryptographically protected
both in transport and in
storage
4. Built-in secure storage is used
for protecting keys
5. No credentials and sensitive
data are sent in clear text
over the wire

1. Data type, format, length,

and range checks are
enforced
2. All data sent from the client
is validated
Data Validation / Parameter Validation
3. No security decision is based
upon parameters (e.g. URL
parameters) that can be
manipulated
4. Input filtering via white list

43
 OWASP Code Review Guide V1.1 2008

validation is used
5. Output encoding is used

1. All exceptions are handled

in a structured manner
2. Privileges are restored to the
appropriate level in case of
errors and exceptions
Error Handling and Exception Management
3. Error messages are scrubbed
so that no sensitive
information is revealed to
the attacker

1. No sensitive information is
stored in clear-text in the
cookie
2. The contents of the
authentication cookies is
encrypted
3. Cookies are configured to
expire
4. Sessions are resistant to
replay attacks
User and Session Management
5. Secure communication
channels are used to
protect authentication
cookies
6. User is forced to re-
authenticate when
performing critical functions
7. Sessions are expired at
logout

44
 OWASP Code Review Guide V1.1 2008

STRIDE Threat & Mitigation Techniques List

Threat Type Mitigation Techniques

1. Appropriate
authentication
Spoofing Identity 2. Protect secret data
3. Don't store secrets

1. Appropriate
authorization
2. Hashes
Tampering with 3. MACs 1. Sensitive information (e.g.
data 4. Digital signatures passwords, PII) is not logged
5. Tamper resistant 2. Access controls (e.g. ACLs)
protocols are enforced on log files to
prevent un-authorized
access
1. Digital signatures 3. Integrity controls (e.g.
2. Timestamps signatures) are enforced on
Repudiation
3. Audit trails log files to provide non-
repudiation
4. Log files provide for audit
1. Authorization trail for sensitive operations
2. Privacy-enhanced and logging of key events
protocols 5. Auditing and logging is
Information
3. Encryption enabled across the tiers on
Disclosure
4. Protect secrets multiple servers
5. Don't store secrets

1. Appropriate
authentication
2. Appropriate
authorization
Denial of Service
3. Filtering
4. Throttling
5. Quality of service

Elevation of 1. Run with least privilege

privilege

When using STRIDE, the following threat-mitigation table can be used to identify techniques that can be
employed to mitigate the threats.

Once threats and corresponding countermeasures are identified, it is possible to derive a threat profile
with the following criteria:

45
 OWASP Code Review Guide V1.1 2008

1. Non mitigated threats: Threats which have no countermeasures and represent vulnerabilities that
can be fully exploited and cause an impact
2. Partially mitigated threats: Threats partially mitigated by one or more countermeasures which
represent vulnerabilities that can only partially be exploited and cause a limited impact
3. Fully mitigated threats: These threats have appropriate countermeasures in place and do not
expose vulnerability and cause impact

MITIGATION STRATEGIES

The objective of risk management is to reduce the impact that the exploitation of a threat can have to
the application. This can be done by responding to a theat with a risk mitigation strategy. In general
there are four options to mitigate threats

1. Do nothing: for example, hoping for the best

2. Informing about the risk: for example, warning user population about the risk
3. Mitigate the risk: for example, by putting countermeasures in place
4. Accept the risk: for example, after evaluating the impact of the exploitation (business impact)
5. Transfer the risk: for example, through contractual agreements and insurance

The decision of which strategy is most appropriate depends on the impact an exploitation of a threat
can have, the likelihood of its occurrence, and the costs for transferring (i.e. costs for insurance) or
avoiding (i.e. costs or losses due redesign) it. That is, such decision is based on the risk a threat poses to
the system. Therefore, the chosen strategy does not mitigate the threat itself but the risk it poses to the
system. Ultimately the overall risk has to take into account the business impact, since this is a critical
factor for the business risk management strategy. One strategy could be to fix only the vulnerabilities for
which the cost to fix is less than the potential business impact derived by the exploitation of the
vulnerability. Another strategy could be to accept the risk when the loss of some security controls (e.g.
Confidentiality, Integrity, and Availability) implies a small degradation of the service, and not a loss of a
critical business function. In some cases, transfer of the risk to another service provider might also be an
option.

46
 OWASP Code Review Guide V1.1 2008

CODE REVIEW METRICS

Code review is an excellent source of metrics that can be used to improve your software development
process. There are two distinct classes of these software metrics: Relative and Absolute.

Absolute metrics are numerical values that describe a trait of the code such as the number of
references to a particular variable in an application, or the number of lines of code (LOC).Absolute
metrics, such as the number of lines of code, do not involve subjective context but are material fact.

Relative metrics are a representation of an attribute that cannot be directly measured and are
subjective and reliant on the context of where the metric was derived. There is no definitive way to
measure such an attribute. Multiple variables are factored into an estimation of the degree of testing
difficulty, and any numeric representation or rating is only an approximation and is subjective.

SOME METRIC BENEFITS

The objective of code review is to detect development errors which may cause vulnerabilities and
hence give rise to an exploit. Code review can also be used to measure the progress of a development
team in their practice of secure application development. It can pinpoint areas where the
development practice is weak, areas where secure development practice is strong, and give a security
practitioner the ability to address the root cause of the weaknesses within a developed solution. It may
give rise to investigation into software development policies and guidelines and the interpretation of
them by the users; communcation is the key.

Metrics can also be recorded relating to the performance of the code reviewers and the accuracy of
the review process, the performance of the code review function, and the efficiency and effectiveness
of the code review function.

47
 OWASP Code Review Guide V1.1 2008

The figure above describes the use of Metrics throughout the code review process.

SECURE DEVELOPMENT METRICS

DEFECT DENSITY:

The average occurrence of programming faults per Lines of code (LOC). This gives a high level view of
the code quality but not much more. Fault density on its own does not give rise to a pragmatic metric.
Defect density would cover minor issues as well as major security flaws in the code; all are treated the
same way. Security of code can not be judged accurately using defect density alone.

LINES OF CODE (LOC):

The count of the executable lines of code. Commented-out code or spaces don't count. This is another
metric in an attempt to quantify the size of the code. This gives a rough estimate but is not particularly
scientific. Some circles of thinking believe that the estimation of an application size by virtue of LOC is
professional malpractice!

48
 OWASP Code Review Guide V1.1 2008

FUNCTION POINT:

The estimation of software size by measuring functionality. The combination of a number of statements
which perform a specific task, independent of programming language used or development
methodology.

RISK DENSITY:

Similar to defect density, but discovered issues are rated by risk (high, medium & low). In doing this we
can give insight into the quality of the code being developed via a [X Risk / LoC] or [Y Risk / Function
Point] value. (X&Y being high, medium or low risks) as defined by your internal application development
policies and standards.

Eg:

4 High Risk Defects per 1000 LOC (Lines of Code)

2 Medium Risk Defects per 3 Function Points

PATH COMPLEXITY/COMPLEXITY-TO-DEFECT/CYCLOMATIC COMPLEXITY

Cyclomatic complexity can help establish risk and stability estimations on an item of code, such as a
class or method or even a complete system. It was defined by Thomas McCabe in the 70's and it easy
to calsulate and apply, hence its usefulness.

CC = Number of decisions +1

A decision could be considered commands such as:

If....else, Switch, Case, Catch, While, do, and so on.....

As the decision count increases, so does the complexity. Complex code leads to less stability and
maintainability.

The more complex the code, the higher risk of defects. One could establish thresholds for Cyclomatic
complexity:

49
Exploring the Variety of Random
Documents with Different Content
 CHAPTER CLXIV.
FREMONT'S THIRD EXPEDITION, AND
ACQUISITION OF CALIFORNIA.
In the month of May 1845, Mr. Frémont, then a brevet captain of
engineers (appointed a lieutenant-colonel of Rifles before he
returned), set out on his third expedition of geographical and
scientific exploration in the Great West. Hostilities had not broken
out between the United States and Mexico; but Texas had been
incorporated; the preservation of peace was precarious, and Mr.
Frémont was determined, by no act of his, to increase the
difficulties, or to give any just cause of complaint to the Mexican
government. His line of observation would lead him to the Pacific
Ocean, through a Mexican province—through the desert parts first,
and the settled part afterwards of the Alta California. Approaching
the settled parts of the province at the commencement of winter, he
left his equipment of 60 men and 200 horses on the frontier, and
proceeded alone to Monterey, to make known to the governor the
object of his coming, and his desire to pass the winter (for the
refreshment of his men and horses) in the uninhabited parts of the
valley of the San Joaquin. The permission was granted; but soon
revoked, under the pretext that Mr. Frémont had come into
California, not to pursue science, but to excite the American settlers
to revolt against the Mexican government. Upon this pretext troops
were raised, and marched to attack him. Having notice of their
approach, he took a position on the mountain, hoisted the flag of
the United States, and determined, with his sixty brave men, to
defend himself to the last extremity—never surrendering; and dying,
if need be, to the last man. A messenger came into his camp,
bringing a letter from the American consul at Monterey, to apprise
him of his danger: that messenger, returning, reported that 2,000
men could not force the American position: and that information had
its effect upon the Mexican commander. Waiting four days in his
mountain camp, and not being attacked, he quit his position,
descended from the mountain, and set out for Oregon, that he
might give no further pretext for complaint, by remaining in
California.
Turning his back on the Mexican possessions, and looking to
Oregon as the field of his future labors, Mr. Frémont determined to
explore a new route to the Wah-lah-math settlements and the tide-
water region of the Columbia, through the wild and elevated region
of the Tla-math lakes. A romantic interest attached to this region
from the grandeur of its features, its lofty mountains, and snow-clad
peaks, and from the formidable character of its warlike inhabitants.
In the first week of May, he was at the north end of the Great Tla-
math lake, and in Oregon—the lake being cut near its south end by
the parallel of 42 degrees north latitude. On the 8th day of that
month, a strange sight presented itself—almost a startling apparition
—two men riding up, and penetrating a region which few ever
approached without paying toll of life or blood. They proved to be
two of Mr. Frémont's old voyageurs, and quickly told their story.
They were part of a guard of six men conducting a United States
officer, who was on his trail with despatches from Washington, and
whom they had left two days back, while they came on to give
notice of his approach, and to ask that assistance might be sent him.
They themselves had only escaped the Indians by the swiftness of
their horses. It was a case in which no time was to be lost, or a
mistake made. Mr. Frémont determined to go himself; and taking ten
picked men, four of them Delaware Indians, he took down the
western shore of the lake on the morning of the 9th (the direction
the officer was to come), and made a ride of sixty miles without a
halt. But to meet men, and not to miss them, was the difficult point
in this trackless region. It was not the case of a high road, where all
travellers must meet in passing each other: at intervals there were
places—defiles, or camping grounds—where both parties must pass;
and watching for these, he came to one in the afternoon, and
decided that, if the party was not killed, it must be there that night.
He halted and encamped; and, as the sun was going down, had the
inexpressible satisfaction to see the four men approaching. The
officer proved to be a lieutenant of the United States marines, who
had been despatched from Washington the November previous, to
make his way by Vera Cruz, the City of Mexico, and Mazatlan to
Monterey, in Upper California, deliver despatches to the United
States' consul there; and then find Mr. Frémont, wherever he should
be. His despatches for Mr. Frémont were only a letter of introduction
from the Secretary of State (Mr. Buchanan), and some letters and
slips of newspapers from Senator Benton and his family, and some
verbal communications from the Secretary of State. The verbal
communications were that Mr. Frémont should watch and counteract
any foreign scheme on California, and conciliate the good will of the
inhabitants towards the United States. Upon this intimation of the
government's wishes, Mr. Frémont turned back from Oregon, in the
edge of which he then was, and returned to California. The letter of
introduction was in the common form, that it might tell nothing if it
fell into the hands of foes, and signified nothing of itself; but it
accredited the bearer, and gave the stamp of authority to what he
communicated; and upon this Mr. Frémont acted: for it was not to
be supposed that Lieutenant Gillespie had been sent so far, and
through so many dangers, merely to deliver a common letter of
introduction on the shores of the Tlamath lake.
The events of some days on the shores of this wild lake, sketched
with the brevity which the occasion requires, may give a glimpse of
the hardships and dangers through which Mr. Frémont pursued
science, and encountered and conquered perils and toils. The night
he met Mr. Gillespie presented one of those scenes to which he was
so often exposed, and which nothing but the highest degree of
vigilance and courage could prevent from being fatal. The camping
ground was on the western side of the lake, the horses picketed with
long halters on the shore, to feed on the grass; and the men
(fourteen in number) sleeping by threes at different fires, disposed
in a square; for danger required them so to sleep as to be ready for
an attack; and, though in the month of May, the elevation of the
place, and the proximity of snow-clad mountains, made the night
intensely cold. His feelings joyfully excited by hearing from home
(the first word of intelligence he had received since leaving the U. S.
a year before), Mr. Frémont sat up by a large fire, reading his letters
and papers, and watching himself over the safety of the camp, while
the men slept. Towards midnight, he heard a movement among the
horses, indicative of alarm and danger. Horses, and especially mules,
become sensitive to danger under long travelling and camping in the
wilderness, and manifest their alarm at the approach of any thing
strange. Taking a six-barrelled pistol in his hand, first making sure of
their ready fire, and, without waking the camp, he went down
among the disturbed animals. The moon shone brightly: he could
see well, but could discover nothing. Encouraged by his presence,
the horses became quiet—poor dumb creatures that could see the
danger, but not tell what they had seen; and he returned to the
camp, supposing it was only some beast of the forest—a bear or
wolf—prowling for food, that had disturbed them. He returned to the
camp fire. Lieutenant Gillespie woke up, and talked with him awhile,
and then lay down again. Finally nature had her course with Mr.
Frémont himself. Excited spirits gave way to exhausted strength. The
day's ride, and the night's excitement demanded the reparation of
repose. He lay down to sleep, and without waking up a man to
watch—relying on the loneliness of the place, and the long ride of
the day, as a security against the proximity of danger. It was the
second time in his twenty thousand miles of wilderness explorations
that his camp had slept without a guard: the first was in his second
expedition, and on an island in the Great Salt Lake, and when the
surrounding water of the lake itself constituted a guard. The whole
camp was then asleep. A cry from Carson roused it. In his sleep he
heard a groan: it was the groan of a man receiving the tomahawk in
his brains. All sprung to their feet. The savages were in the camp:
the hatchet and the winged arrow were at work. Basil Lajeunesse, a
brave and faithful young Frenchman, the follower of Frémont in all
his expeditions, was dead: an Iowa was dead: a brave Delaware
Indian, one of those who had accompanied Frémont from Missouri,
was dying: it was his groan that awoke Carson. Another of the
Delawares was a target for arrows, from which no rifle could save
him—only avenge him. The savages had waited till the moon was in
the trees, casting long shadows over the sleeping camp: then
approaching from the dark side, with their objects between
themselves and the fading light, they used only the hatchet and the
formidable bow, whose arrow went to its mark without a flash or a
sound to show whence it came. All advantages were on the side of
the savages: but the camp was saved! the wounded protected from
massacre, and the dead from mutilation. The men, springing to their
feet, with their arms in their hands, fought with skill and courage. In
the morning, Lieutenant Gillespie recognized, in the person of one of
the slain assailants, the Tlamath chief who the morning before had
given him a salmon, in token of friendship, and who had followed
him all day to kill and rob his party at night—a design in which he
would certainly have been successful had it not been for the
promptitude and precision of Mr. Frémont's movement. Mr. Frémont
himself would have been killed, when he went to the horses, had it
not been that the savages counted upon the destruction of the
whole camp, and feared to alarm it by killing one, before the general
massacre.
It was on the 9th of May—a day immortalized by American arms
at Resaca de la Palma—that this fierce and bloody work was done in
the far distant region of the Tlamath lakes.
The morning of the 10th of May was one of gloom in the camp.
The evening sun of the 9th had set upon it full of life and joy at a
happy meeting: the same sun rose upon it the next morning, stained
with blood, ghastly with the dead and wounded, and imposing
mournful duties on the survivors. The wounded were to be carried—
the dead to be buried; and so buried as to be hid and secured from
discovery and violation. They were carried ten miles, and every
precaution taken to secure the remains from the wolf and the
savage: for men, in these remote and solitary dangers, become
brothers, and defend each other living and dead. The return route
lay along the shore of the lake, and during the day the distant
canoes of the savages could be seen upon it, evidently watching the
progress of the party, and meditating a night attack upon it. All
precautions, at the night encampment, were taken for security—
horses and men enclosed in a breastwork of great trees, cut down
for the purpose, and half the men constantly on the watch. At
leaving in the morning, an ambuscade was planted—and two of the
Tlamaths were killed by the men in ambush—a successful return of
their own mode of warfare. At night the main camp, at the north end
of the lake, was reached. It was strongly intrenched, and could not
be attacked; but the whole neighborhood was infested, and scouts
and patrols were necessary to protect every movement. In one of
these excursions the Californian horse, so noted for spirit and
docility, showed what he would do at the bid of his master. Carson's
rifle had missed fire, at ten feet distance. The Tlamath long bow,
arrow on the string, was bending to the pull. All the rifles in the
party could not have saved him. A horse and his rider did it. Mr.
Frémont touched his horse; he sprang upon the savage! and the
hatchet of a Delaware completed the deliverance of Carson. It was a
noble horse, an iron gray, with a most formidable name—el Toro del
Sacramento: and which vindicated his title to the name in all the
trials of travel, courage, and performance to which he was
subjected. It was in the midst of such dangers as these, that science
was pursued by Mr. Frémont; that the telescope was carried to read
the heavens; the barometer to measure the elevations of the earth;
the thermometer to gauge the temperature of the air; the pencil to
sketch the grandeur of mountains, and to paint the beauty of
flowers; the pen to write down whatever was new, or strange, or
useful in the works of nature. It was in the midst of such dangers,
and such occupations as these, and in the wildest regions of the
Farthest West, that Mr. Frémont was pursuing science and shunning
war, when the arrival of Lieutenant Gillespie, and his
communications from Washington, suddenly changed all his plans,
turned him back from Oregon, and opened a new and splendid field
of operations in California itself. He arrived in the valley of the
Sacramento in the month of May, 1846, and found the country
alarmingly, and critically situated. Three great operations, fatal to
American interests, were then going on, and without remedy, if not
arrested at once. These were: 1. The massacre of the Americans,
and the destruction of their settlements, in the valley of the
Sacramento. 2. The subjection of California to British protection. 3.
The transfer of the public domain to British subjects. And all this
with a view to anticipate the events of a Mexican war, and to shelter
California from the arms of the United States.
The American settlers sent a deputation to the camp of Mr.
Frémont, in the valley of the Sacramento, laid all these dangers
before him, and implored him to place himself at their head and
save them from destruction. General Castro was then in march upon
them: the Indians were incited to attack their families, and burn
their wheat fields, and were only waiting for the dry season to apply
the torch. Juntas were in session to transfer the country to Great
Britain: the public domain was passing away in large grants to British
subjects: a British fleet was expected on the coast: the British vice
consul, Forbes, and the emissary priest, Macnamara, ruling and
conducting every thing: and all their plans so far advanced as to
render the least delay fatal. It was then the beginning of June. War
had broken out between the United States and Mexico, but that was
unknown in California. Mr. Frémont had left the two countries at
peace when he set out upon his expedition, and was determined to
do nothing to disturb their relations: he had even left California to
avoid giving offence; and to return and take up arms in so short a
time was apparently to discredit his own previous conduct as well as
to implicate his government. He felt all the responsibilities of his
position; but the actual approach of Castro, and the immediate
danger of the settlers, left him no alternative. He determined to put
himself at the head of the people, and to save the country. To
repulse Castro was not sufficient: to overturn the Mexican
government in California, and to establish Californian Independence,
was the bold resolve, and the only measure adequate to the
emergency. That resolve was taken, and executed with a celerity
that gave it a romantic success. The American settlers rushed to his
camp—brought their arms, horses and ammunition—were formed
into a battalion; and obeyed with zeal and alacrity the orders they
received. In thirty days all the northern part of California was freed
from Mexican authority—Independence proclaimed—the flag of
Independence raised—Castro flying to the south—the American
settlers saved from destruction; and the British party in California
counteracted and broken up in all their schemes.
This movement for Independence was the salvation of California,
and snatched it out of the hands of the British at the moment they
were ready to clutch it. For two hundred years—from the time of the
navigator Drake, who almost claimed it as a discovery, and placed
the English name of New Albion upon it—the eye of England has
been upon California; and the magnificent bay of San Francisco, the
great seaport of the North Pacific Ocean, has been surveyed as her
own. The approaching war between Mexico and the United States
was the crisis in which she expected to realize the long-deferred
wish for its acquisition; and carefully she took her measures
accordingly. She sent two squadrons to the Pacific as soon as Texas
was incorporated—well seeing the actual war which was to grow out
of that event—a small one into the mouth of the Columbia, an
imposing one to Mazatlan, on the Mexican coast, to watch the
United States squadron there, and to anticipate its movements upon
California. Commodore Sloat commanding the squadron at Mazatlan,
saw that he was watched, and pursued, by Admiral Seymour, who
lay alongside of him, and he determined to deceive him. He stood
out to sea, and was followed by the British Admiral. During the day
he bore west, across the ocean, as if going to the Sandwich Islands:
Admiral Seymour followed. In the night the American commodore
tacked, and ran up the coast towards California: the British admiral,
not seeing the tack, continued on his course, and went entirely to
the Sandwich Islands before he was undeceived. Commodore Sloat
arrived before Monterey on the second of July, entering the port
amicably, and offering to salute the town, which the authorities
declined on the pretext that they had no powder to return it—in
reality because they momentarily expected the British fleet.
Commodore Sloat remained five days before the town, and until he
heard of Frémont's operations: then believing that Frémont had
orders from his government to take California, he having none
himself, he determined to act himself. He received the news of
Frémont's successes on the 6th day of July: on the 7th he took the
town of Monterey, and sent a despatch to Frémont. This latter came
to him in all speed, at the head of his mounted force. Going
immediately on board the commodore's vessel, an explanation took
place. The commodore learnt with astonishment that Frémont had
no orders from his government to commence hostilities—that he had
acted entirely on his own responsibility. This left the commodore
without authority for having taken Monterey; for still at this time, the
commencement of the war with Mexico was unknown. Uneasiness
came upon the commodore. He remembered the fate of Captain
Jones in making the mistake of seizing the town once before in time
of peace. He resolved to return to the United States, which he did—
turning over the command of the squadron to Commodore Stockton,
who had arrived on the 15th. The next day (16th) Admiral Seymour
arrived; his flagship the Collingwood, of 80 guns, and his squadron
the largest British fleet ever seen in the Pacific. To his astonishment
he beheld the American flag flying over Monterey, the American
squadron in its harbor, and Frémont's mounted riflemen encamped
over the town. His mission was at an end. The prize had escaped
him. He attempted nothing further, and Frémont and Stockton
rapidly pressed the conquest of California to its conclusion. The
subsequent military events can be traced by any history: they were
the natural sequence of the great measure conceived and executed
by Frémont before any squadron had arrived upon the coast, before
he knew of any war with Mexico, and without any authority from his
government, except the equivocal and enigmatical visit of Mr.
Gillespie. Before the junction of Mr. Frémont with Commodore Sloat
and Stockton, his operations had been carried on under the flag of
Independence—the Bear Flag, as it was called—the device of the
bear being adopted on account of the courageous qualities of that
animal (the white bear), which never gives the road to men,—which
attacks any number,—and fights to the last with increasing ferocity,
with amazing strength of muscle, and with an incredible tenacity of
the vital principle—never more formidable and dangerous than when
mortally wounded. The Independents took the device of this bear for
their flag, and established the independence of California under it:
and in joining the United States forces, hauled down this flag, and
hoisted the flag of the United States. And the fate of California
would have been the same whether the United States squadrons
had arrived, or not; and whether the Mexican war had happened, or
not. California was in a revolutionary state, already divided from
Mexico politically as it had always been geographically. The last
governor-general from Mexico, Don Michel Toreno, had been resisted
—fought—captured—and shipped back to Mexico, with his 300 cut-
throat soldiers. An insurgent government was in operation,
determined to be free of Mexico, sensible of inability to stand alone,
and looking, part to the United States, part to Great Britain, for the
support which they needed. All the American settlers were for the
United States protection, and joined Frémont. The leading
Californians were also joining him. His conciliatory course drew them
rapidly to him. The Picos, who were the leading men of the revolt
(Don Pico, Don Andres, and Don Jesus), became his friends.
California, become independent of Mexico by the revolt of the Picos,
and independent of them by the revolt of the American settlers, had
its destiny to fulfil—which was, to be handed over to the United
States. So that its incorporation with the American Republic was
equally sure in any, and every event.
 CHAPTER CLXV.
PAUSE IN THE WAR: SEDENTARY TACTICS:
"MASTERLY INACTIVITY."
Arriving at Washington before the commencement of the session
of '46-'47, Mr. Benton was requested by the President to look over
the draught of his proposed message to Congress (then in
manuscript), and to make the remarks upon it which he might think
it required; and in writing. Mr. Benton did so, and found a part to
which he objected, and thought ought to be omitted. It was a
recommendation to Congress to cease the active prosecution of the
war, to occupy the conquered part of the country (General Taylor
had then taken Monterey) with troops in forts and stations, and to
pass an act establishing a temporary government in the occupied
part; and to retain the possession until the peace was made. This
recommendation, and the argument in support of it, spread over
four pages of the message—from 101 to 105. Mr. Benton objected to
the whole plan, and answered to it in an equal, or greater number of
pages, and to the entire conviction and satisfaction of the President.
1. The sedentary occupation was objected to as being entirely
contrary to the temper of the American people, which was active,
and required continual "going ahead" until their work was finished.
2. It was a mode of warfare suited to the Spanish temper, which
loved procrastination, and could beat the world at it, and had sat-out
the Moors seven hundred years in the South of Spain and the
Visigoths three hundred years in the north of it; and would certainly
out-sit us in Mexico. 3. That he could govern the conquered country
under the laws of nations, without applying to Congress, to be
worried upon the details of the act, and rousing the question of
annexation by conquest, and that beyond the Rio Grande; for the
proposed line was to cover Monterey, and to run east and west
entirely across the country. These objections, pursued through their
illustrations, were entirely convincing to the President, and he frankly
gave up the sedentary project.
But it was a project which had been passed upon in the cabinet,
and not only adopted but began to be executed. The Secretary at
War, Mr. Marcy, had officially refused to accept proffered volunteers
from the governors of several States, saying to them—"A sufficient
amount of force for the prosecution of the war had already been
called into service:" and a premium of two dollars a head had been
offered to all persons who could bring in a recruit to the regular
army—the regulars being the reliance for the sedentary occupation.
The cabinet adhered to their policy. The President convoked them
again, and had Mr. Benton present to enforce his objections; but
without much effect. The abandonment of the sedentary policy
required the adoption of an active one, and for that purpose the
immediate calling out of ten regiments of volunteers had been
recommended by Mr. Benton; and this call would result at once from
the abandonment of the sedentary scheme. Here the pride of
consistency came in to play its part. The Secretary at War said he
had just refused to accept any more volunteers, and informed the
governors of two States that the government had troops enough to
prosecute the war; and urged that it would be contradictory now to
call out ten regiments. The majority of the cabinet sided with him;
but the President retained Mr. Benton to a private interview—talked
the subject all over—and finally came to the resolution to act for
himself, regardless of the opposition of the major part of his cabinet.
It was then in the night, and the President said he would send the
order to the Secretary at War in the morning to call out the ten
regiments—which he did: but the Secretary, higgling to the last, got
one regiment abated: so that nine instead of ten were called out:
but these nine were enough. They enabled Scott to go to Mexico,
and Taylor to conquer at Buena Vista, and to finish the war
victoriously.
 A comic mistake grew out of this change in the President's
message, which caused the ridicule of the sedentary line to be
fastened on Mr. Calhoun—who in fact had counselled it. When the
message was read in the Senate, Mr. Westcott, of Florida, believing it
remained as it had been drawn up, and induced by Mr. Calhoun, with
whose views he was acquainted, made some motion upon it,
significant of approbatory action. Mr. Benton asked for the reading of
the part of the message referred to. Mr. Westcott searched, but
could not find it: Mr. Calhoun did the same. Neither could find the
passage. Inquiring and despairing looks were exchanged: and the
search for the present was adjourned. Of course it was never found.
Afterwards Mr. Westcott said to Mr. Benton that the President had
deceived Mr. Calhoun—had told him that the sedentary line was
recommended in the message, when it was not. Mr. Benton told him
there was no deception—that the recommendation was in the
message when he said so, but had been taken out (and he explained
how) and replaced by an urgent recommendation for a vigorous
prosecution of the war. But the secret was kept for the time. The
administration stood before the country vehement for war, and
loaded with applause for their spirit. Mr. Calhoun remained mystified,
and adhered to the line, and incurred the censure of opposing the
administration which he professed to support. He brought forward
his plan in all its detail—the line marked out—the number of forts
and stations necessary—and the number of troops necessary to
garrison them: and spoke often, and earnestly in its support: but to
no purpose. His plan was entirely rejected, nor did I ever hear of any
one of the cabinet offering to share with him in the ridicule which he
brought upon himself for advocating a plan so preposterous in itself,
and so utterly unsuited to the temper of our people. It was in this
debate, and in support of this sedentary occupation that Mr. Calhoun
characterized that proposed inaction as "a masterly inactivity:" a fine
expression of the Earl of Chatham—and which Mr. Calhoun had
previously used in the Oregon debate in recommending us to do
nothing there, and leave it to time to perfect our title. Seven years
afterwards the establishment of a boundary between the United
States and Mexico was attempted by treaty in the latitude of this
proposed line of occupation—a circumstance,—one of the
circumstances,—which proves that Mr. Calhoun's plans and spirit
survive him.
In all that passed between the President and Mr. Benton about
this line, there was no suspicion on the part of either of any design
to make it permanent; nor did any thing to that effect appear in Mr.
Calhoun's speeches in favor of it; but the design was developed at
the time of the ratification of the treaty of peace, and has since been
attempted by treaty; and is a design which evidently connects itself
with, what is called, preserving the equilibrium of the States (free
and slave) by adding on territory for slave States—and to increase
the Southern margin for the "United States South," in the event of a
separation of the two classes of States.
 CHAPTER CLXVI.
THE WILMOT PROVISO; OR, PROHIBITION OF
SLAVERY IN THE TERRITORIES: ITS
INUTILITY AND MISCHIEF.
Scarcely was the war with Mexico commenced when means,
different from those of arms, were put in operation to finish it. One
of these was the return of the exiled Santa Anna (as has been
shown) to his country, and his restoration to power, under the belief
that he was favorable to peace, and for which purpose arrangements
began to be made from the day of the declaration of the war—or
before. In the same session another move was made in the same
direction, that of getting peace by peaceable means, in an
application made to Congress by the President, to place three
millions of dollars at his disposal, to be used in negotiating for a
boundary which should give us additional territory: and that
recommendation not having been acted upon at the war session,
was renewed at the commencement of the next one. It was
recommended as an "important measure for securing a speedy
peace;" and as an argument in favor of granting it, a sum of two
millions similarly placed at the disposition of Mr. Jefferson when
about to negotiate for Florida (which ended in the acquisition of
Louisiana), was plead as a precedent; and justly. Congress, at this
second application, granted the appropriation; but while it was
depending, Mr. Wilmot, a member of Congress, from Pennsylvania,
moved a proviso, that no part of the territory to be acquired should
be open to the introduction of slavery. It was a proposition not
necessary for the purpose of excluding slavery, as the only territory
to be acquired was that of New Mexico and California, where slavery
was already prohibited by the Mexican laws and constitution; and
where it could not be carried until those laws should be repealed,
and a law for slavery passed. The proviso was nugatory, and could
answer no purpose but that of bringing on a slavery agitation in the
United States; for which purpose it was immediately seized upon by
Mr. Calhoun and his friends, and treated as the greatest possible
outrage and injury to the slave States. Congress was occupied with
this proviso for two sessions, became excessively heated on the
subject, and communicated its heat to the legislatures of the slave
States—by several of which conditional disunion resolutions were
passed. Every where, in the slave States, the Wilmot Proviso became
a Gorgon's head—a chimera dire—a watchword of party, and the
synonyme of civil war and the dissolution of the Union. Many
patriotic members were employed in resisting the proviso as a bona
fide cause of breaking up the Union, if adopted; many amiable and
gentle-tempered members were employed in devising modes of
adjusting and compromising it; a few, of whom Mr. Benton was one,
produced the laws and the constitution of Mexico to show that New
Mexico and California were free from slavery; and argued that
neither party had any thing to fear, or to hope—the free soil party
nothing to fear, because the soil was now free; the slave soil party
nothing to hope, because they could not take a step to make it slave
soil, having just invented the dogma of "No power in Congress to
legislate upon slavery in territories." Never were two parties so
completely at loggerheads about nothing: never did two parties
contend more furiously against the greatest possible evil. Close
observers, who had been watching the progress of the slavery
agitation since its inauguration in Congress in 1835, knew it to be a
game played by the abolitionists on one side and the disunionists on
the other, to accomplish their own purposes. Many courageous men
denounced it as such—as a game to be kept up for the political
benefit of the players; and deplored the blindness which could not
see their determination to keep it agoing to the last possible
moment, and to the production of the greatest possible degree of
national and sectional exasperation. It was while this contention was
thus raging, that Mr. Calhoun wrote a confidential letter to a member
of the Alabama legislature, hugging this proviso to his bosom as a
fortunate event—as a means of "forcing the issue" between the
North and the South; and deprecating any adjustment, compromise,
or defeat of it, as a misfortune to the South: and which letter has
since come to light. Gentle and credulous people, who believed him
to be in earnest when he was sounding the tocsin to rouse the
States, instigating them to pass disunion resolutions, and stirring up
both national and village orators to attack the proviso unto death:
such persons must be amazed to read in that exhumed letter,
written during the fiercest of the strife, these ominous words:

"With this impression I would regard any compromise or

adjustment of the proviso, or even its defeat, without meeting
the danger in its whole length and breadth, as very unfortunate
for us. It would lull us to sleep again, without removing the
danger, or materially diminishing it."

This issue to be forced was a separation of the slave and the free
States; the means, a commercial non-intercourse, in shutting the
slave State seaports against the vessels of the free States; the
danger to be met, was in the trial of this issue, by the means
indicated; which were simply high treason when pursued to the
overt act. Mr. Calhoun had flinched from that act in the time of
Jackson, but he being dead, and no more Jacksons at the head of
the government, he rejoiced in another chance of meeting the
danger—meeting it in all its length and breadth; and deprecated the
loss of the proviso as the loss of this chance.
Truly the abolitionists and the nullifiers were necessary to each
other—the two halves of a pair of shears, neither of which could cut
until joined together. Then the map of the Union was in danger; for
in their conjunction, that map was cloth between the edges of the
shears. And this was that Wilmot Proviso, which for two years
convulsed the Union, and prostrated men of firmness and patriotism
—a thing of nothing in itself, but magnified into a hideous reality,
and seized upon to conflagrate the States and dissolve the Union.
The Wilmot Proviso was not passed: that chance of forcing the issue
was lost: another had to be found, or made.
 CHAPTER CLXVII.
MR. CALHOUN'S SLAVERY RESOLUTIONS, AND
DENIAL OF THE RIGHT OF CONGRESS TO
PROHIBIT SLAVERY IN A TERRITORY.
On Friday, the 19th of February, Mr. Calhoun introduced into the
Senate his new slavery resolutions, prefaced by an elaborate speech,
and requiring an immediate vote upon them. They were in these
words:

"Resolved, That the territories of the United States belong to

the several States composing this Union, and are held by them
as their joint and common property.
"Resolved, That Congress, as the joint agent and
representative of the States of this Union, has no right to make
any law, or do any act whatever, that shall directly, or by its
effects, make any discrimination between the States of this
Union, by which any of them shall be deprived of its full and
equal right in any territory of the United States acquired or to
be acquired.
"Resolved, That the enactment of any law which should
directly, or by its effects, deprive the citizens of any of the
States of this Union from emigrating, with their property, into
any of the territories of the United States, will make such
discrimination, and would, therefore, be a violation of the
constitution, and the rights of the States from which such
citizens emigrated, and in derogation of that perfect equality
which belongs to them as members of this Union, and would
tend directly to subvert the Union itself.
 "Resolved, That it is a fundamental principle in our political
creed, that a people, in forming a constitution, have the
unconditional right to form and adopt the government which
they may think best calculated to secure their liberty, prosperity,
and happiness; and that, in conformity thereto, no other
condition is imposed by the federal constitution on a State, in
order to be admitted into this Union, except that its constitution
shall be republican; and that the imposition of any other by
Congress would not only be in violation of the constitution, but
in direct conflict with the principle on which our political system
rests."

These resolutions, although the sense is involved in circumlocutory

phrases, are intelligible to the point, that Congress has no power to
prohibit slavery in a territory, and that the exercise of such a power
would be a breach of the constitution, and leading to the subversion
of the Union. Ostensibly the complaint was, that the emigrant from
the slave State was not allowed to carry his slave with him: in reality
it was that he was not allowed to carry the State law along with him
to protect his slave. Placed in that light, which is the true one, the
complaint is absurd: presented as applying to a piece of property
instead of the law of the State, it becomes specious—has deluded
whole communities; and has led to rage and resentment, and hatred
of the Union. In support of these resolutions the mover made a
speech in which he showed a readiness to carry out in action, to
their extreme results, the doctrines they contained, and to appeal to
the slave-holding States for their action, in the event that the Senate
should not sustain them. This was the concluding part of his speech:

"Well, sir, what if the decision of this body shall deny to us

this high constitutional right, not the less clear because deduced
from the whole body of the instrument and the nature of the
subject to which it relates? What, then, is the question? I will
not undertake to decide. It is a question for our constituents—
the slave-holding States. A solemn and a great question. If the
decision should be adverse, I trust and do believe that they will
 take under solemn consideration what they ought to do. I give
no advice. It would be hazardous and dangerous for me to do
so. But I may speak as an individual member of that section of
the Union. There I drew my first breath. There are all my hopes.
There is my family and connections. I am a planter—a cotton
planter. I am a Southern man, and a slave-holder; a kind and a
merciful one, I trust—and none the worse for being a slave-
holder. I say, for one, I would rather meet any extremity upon
earth than give up one inch of our equality—one inch of what
belongs to us as members of this great republic. What,
acknowledge inferiority! The surrender of life is nothing to
sinking down into acknowledged inferiority.
"I have examined this subject largely—widely. I think I see
the future if we do not stand up as we ought. In my humble
opinion, in that case, the condition of Ireland is prosperous and
happy—the condition of Hindostan is prosperous and happy—
the condition of Jamaica is prosperous and happy, to what the
Southern States will be if they should not now stand up
manfully in defence of their rights".

When these resolutions were read, Mr. Benton rose in his place,
and called them "firebrand." Mr. Calhoun said he had expected the
support of Mr. Benton "as the representative of a slave-holding
State." Mr. Benton answered that it was impossible that he could
have expected such a thing. Then, said Mr. Calhoun, I shall know
where to find the gentleman. To which Mr. Benton: "I shall be found
in the right place—on the side of my country and the Union." This
answer, given on that day, and on the spot, is one of the incidents of
his life which Mr. Benton will wish posterity to remember.
Mr. Calhoun demanded the prompt consideration of his
resolutions, giving notice that he would call them up the next day,
and press them to a speedy and final vote. He did call them up, but
never called for the vote, nor was any ever had: nor would a vote
have any practical consequence, one way or the other. The
resolutions were abstractions, without application. They asserted a
constitutional principle, which could not be decided, one way or the
other, by the separate action of the Senate; not even in a bill, much
less in a single and barren set of resolves. No vote was had upon
them. The condition had not happened on which they were to be
taken up by the slave States; but they were sent out to all such
States, and adopted by some of them; and there commenced the
great slavery agitation, founded upon the dogma of "no power in
Congress to legislate upon slavery in the territories," which has led
to the abrogation of the Missouri compromise line—which has filled
the Union with distraction—and which is threatening to bring all
federal legislation, and all federal elections, to a mere sectional
struggle, in which, one-half of the States is to be arrayed against the
other. The resolves were evidently introduced for the mere purpose
of carrying a question to the slave States on which they could be
formed into a unit against the free States; and they answered that
purpose as well on rejection by the Senate as with it; and were
accordingly used in conformity to their design without any such
rejection, which—it cannot be repeated too often—could in no way
have decided the constitutional question which they presented.
These were new resolutions—the first of their kind in the (almost)
sixty years' existence of the federal government—contrary to its
practice during that time—contrary to Mr. Calhoun's slavery
resolutions of 1838—contrary to his early and long support of the
Missouri compromise—and contrary to the re-enactment of that line
by the authors of the Texas annexation law. That re-enactment had
taken place only two years before, and was in the very words of the
anti-slavery ordinance of '87, and of the Missouri compromise
prohibition of 1820; and was voted for by the whole body of the
annexationists, and was not only conceived and supported by Mr.
Calhoun, then Secretary of State, but carried into effect by him in
the despatch of that messenger to Texas in the expiring moments of
his power. The words of the re-enactment were: "And in such State,
or States as shall be formed out of said territory north of the said
Missouri compromise line, slavery or involuntary servitude (except
for crime) shall be prohibited." This clause re-established that
compromise line in all that long extent of it which was ceded to
Spain by the treaty of 1819, which became Texian by her separation
from Mexico, and which became slave soil under her laws and
constitution. So that, up to the third day of March, in the year 1845
—not quite two years before the date of these resolutions—Mr.
Calhoun by authentic acts, and the two Houses of Congress by
recorded votes, and President Tyler by his approving signature,
acknowledged the power of Congress to prohibit slavery in a
territory! and not only acknowledged the power, but exerted it! and
actually prohibited slavery in a long slip of country, enough to make
a "State or States," where it then legally existed. This fact was
formally brought out in the chapter of this volume which treats of
the legislative annexation of Texas; and those who wish to see the
proceeding in detail may find it in the journals of the two Houses of
Congress, and in the congressional history of the time.
These resolutions of 1847, called fire-brand at the time, were
further characterized as nullification a few days afterwards, when Mr.
Benton said of them, that, "as Sylla saw in the young Cæsar many
Mariuses, so did he see in them many nullifications."
 CHAPTER CLXVIII.
THE SLAVERY AGITATION: DISUNION: KEY TO
MR. CALHOUN'S POLICY: FORCING THE
ISSUE: MODE OF FORCING IT.
In the course of this year, and some months after the submission
of his resolutions in the Senate denying the right of Congress to
abolish slavery in a territory, Mr. Calhoun wrote a letter to a member
of the Alabama Legislature, which furnishes the key to unlock his
whole system of policy in relation to the slavery agitation, and its
designs, from his first taking up the business in Congress in the year
1835, down to the date of the letter; and thereafter. The letter was
in reply to one asking his opinion "as to the steps which should be
taken" to guard the rights of the South; and was written in a feeling
of personal confidence to a person in a condition to take steps; and
which he has since published to counteract the belief that Mr.
Calhoun was seeking the dissolution of the Union. The letter
disavows such a design, and at the same time proves it—
recommends forcing the issue between the North and the South,
and lays down the manner in which it should be done. It opens with
this paragraph:

"I am much gratified with the tone and views of your letter,
and concur entirely in the opinion you express, that instead of
shunning, we ought to court the issue with the North on the
slavery question. I would even go one step further, and add that
it is our duty—due to ourselves, to the Union, and our political
institutions, to force the issue on the North. We are now
stronger relatively than we shall be hereafter, politically and
morally. Unless we bring on the issue, delay to us will be
 dangerous indeed. It is the true policy of those enemies who
seek our destruction. Its effects are, and have been, and will be
to weaken us politically and morally, and to strengthen them.
Such has been my opinion from the first. Had the South, or
even my own State backed me, I would have forced the issue
on the North in 1835, when the spirit of abolitionism first
developed itself to any considerable extent. It is a true maxim,
to meet danger on the frontier, in politics as well as war. Thus
thinking, I am of the impression, that if the South act as it
ought, the Wilmot Proviso, instead of proving to be the means
of successfully assailing us and our peculiar institution, may be
made the occasion of successfully asserting our equality and
rights, by enabling us to force the issue on the North.
Something of the kind was indispensable to rouse and unite the
South. On the contrary, if we should not meet it as we ought, I
fear, greatly fear, our doom will be fixed. It would prove that we
either have not the sense or spirit to defend ourselves and our
institutions."

The phrase "forcing the issue" is here used too often, and for a
purpose too obvious, to need remark. The reference to his
movement in 1835 confirms all that was said of that movement at
the time by senators from both sections of the Union, and which has
been related in chapter 131 of the first volume of this View. At that
time Mr. Calhoun characterized his movement as defensive—as done
in a spirit of self-defence: it was then characterized by senators as
aggressive and offensive: and it is now declared in this letter to have
been so. He was then openly told that he was playing into the hands
of the abolitionists, and giving them a champion to contend with,
and the elevated theatre of the American Senate for the
dissemination of their doctrines, and the production of agitation and
sectional division. All that is now admitted, with a lamentation that
the South, and not even his own State, would stand by him then in
forcing the issue. So that chance was lost. Another was now
presented. The Wilmot Proviso, so much deprecated in public, is
privately saluted as a fortunate event, giving another chance for
forcing the issue. The letter proceeds:

"But in making up the issue, we must look far beyond the

proviso. It is but one of many acts of aggression, and, in my
opinion, by no means the most dangerous or degrading, though
more striking and palpable."

In looking beyond the proviso (the nature of which has been

explained in a preceding chapter) Mr. Calhoun took up the recent act
of the General Assembly of Pennsylvania, repealing the slave
sojournment law within her limits, and obstructing the recovery of
fugitive slaves—saying:

"I regard the recent act of Pennsylvania, and laws of that

description, passed by other States, intended to prevent or
embarrass the reclamation of fugitive slaves, or to liberate our
domestics when travelling with them in non-slaveholding States,
as unconstitutional. Insulting as it is, it is even more dangerous.
I go further, and hold that if we have a right to hold our slaves,
we have a right to hold them in peace and quiet, and that the
toleration, in the non-slaveholding States, of the establishment
of societies and presses, and the delivery of lectures, with the
express intention of calling in question our right to our slaves,
and of seducing and abducting them from the service of their
masters, and finally overthrowing the institution itself, as not
only a violation of international laws, but also of the Federal
compact. I hold, also, that we cannot acquiesce in such wrongs,
without the certain destruction of the relation of master and
slave, and without the ruin of the South."

The acts of Pennsylvania here referred to are justly complained of,

but with the omission to tell that these injurious acts were the fruit
of his own agitation policy, and in his own line of forcing issues; and
that the repeal of the sojournment law, which had subsisted since
the year 1780, and the obstruction of the fugitive slave act, which
had been enforced since 1793, only took place twelve years after he
had commenced slavery agitation in the South, and were legitimate
consequences of that agitation, and of the design to force the issue
with the North. The next sentence of the letter reverts to the Wilmot
Proviso, and is of momentous consequence as showing that Mr.
Calhoun, with all his public professions in favor of compromise and
conciliation, was secretly opposed to any compromise or adjustment,
and actually considered the defeat of the proviso as a misfortune to
the South. Thus:

"With this impression, I would regard any compromise or

adjustment of the proviso, or even its defeat, without meeting
the danger in its whole length and breadth, as very unfortunate
for us. It would lull us to sleep again, without removing the
danger, or materially diminishing it."

So that, while this proviso was, publicly, the Pandora's box which
filled the Union with evil, and while it was to Mr. Calhoun and his
friends the theme of endless deprecation, it was secretly cherished
as a means of keeping up discord, and forcing the issue between the
North and the South. Mr. Calhoun then proceeds to the serious
question of disunion, and of the manner in which the issue could be
forced.

"This brings up the question, how can it be so met, without

resorting to the dissolution of the Union? I say without its
dissolution, for, in my opinion, a high and sacred regard for the
constitution, as well as the dictates of wisdom, make it our duty
in this case, as well as all others, not to resort to, or even to
look to that extreme remedy, until all others have failed, and
then only in defence of our liberty and safety. There is, in my
opinion, but one way in which it can be met; and that is the one
indicated in my letter to Mr. ——, and to which you allude in
yours to me, viz., by retaliation. Why I think so, I shall now
proceed to explain."
 Then follows an argument to justify retaliation, by representing
the constitution as containing provisions, he calls them stipulations,
some in favor of the slaveholding, and some in favor of the non-
slaveholding States, and the breach of any of which, on one side,
authorizes a retaliation on the other; and then declaring that
Pennsylvania, and other States, have violated the provision in favor
of the slave States in obstructing the recovery of fugitive slaves, he
proceeds to explain his remedy—saying:

"There is and can be but one remedy short of disunion, and

that is to retaliate on our part, by refusing to fulfil the
stipulations in their favor, or such as we may select, as the most
efficient. Among these, the right of their ships and commerce to
enter and depart from our ports is the most effectual, and can
be enforced. That the refusal on their part would justify us to
refuse to fulfil on our part those in their favor, is too clear to
admit of argument. That it would be effectual in compelling
them to fulfil those in our favor can hardly be doubted, when
the immense profit they make by trade and navigation out of us
is regarded; and also the advantages we would derive from the
direct trade it would establish between the rest of the world and
our ports."

Retaliation by closing the ports of the State against the commerce

of the offending State: and this called a constitutional remedy, and a
remedy short of disunion. It is, on the contrary, a flagrant breach of
the constitution, and disunion itself, and that at the very point which
caused the Union to be formed. Every one acquainted with the
history of the formation of the federal constitution, knows that it
grew out of the single question of commerce—the necessity of its
regulation between the States to prevent them from harassing each
other, and with foreign nations to prevent State rivalries for foreign
trade. To stop the trade with any State is, therefore, to break the
Union with that State; and to give any advantage to a foreign nation
over a State, would be to break the constitution again in the
fundamental article of its formation; and this is what the retaliatory
remedy of commercial non-intercourse arrives at—a double breach
of the constitution—one to the prejudice of sister States, the other in
favor of foreign nations. For immediately upon this retaliation upon a
State, and as a consequence of it, a great foreign trade is to grow
up with all the world. The letter proceeds with further instructions
upon the manner of executing the retaliation:

"My impression is, that it should be restricted to sea-going

vessels, which would leave open the trade of the valley of the
Mississippi to New Orleans by river, and to the other Southern
cities by railroad; and tend thereby to detach the North-western
from the North-eastern States."

This discloses a further feature in the plan of forcing the issue.

The North-eastern States were to be excluded from Southern
maritime commerce: the North-western States were to be admitted
to it by railroad, and also allowed to reach New Orleans by the
Mississippi River. And this discrimination in favor of the North-
western States was for the purpose of detaching them from the
North-east. Detach is the word. And that word signifies to separate,
disengage, disunite, part from: so that the scheme of disunion
contemplated the inclusion of the North-western States in the
Southern division. The State of Missouri was one of the principal of
these States, and great efforts were made to gain her over, and to
beat down Senator Benton who was an obstacle to that design. The
letter concludes by pointing out the only difficulty in the execution of
this plan, and showing how to surmount it.

"There is but one practical difficulty in the way; and that is, to
give it force, it will require the co-operation of all the slave-
holding States lying on the Atlantic Gulf. Without that, it would
be ineffective. To get that is the great point, and for that
purpose a convention of the Southern States is indispensable.
Let that be called, and let it adopt measures to bring about the
co-operation, and I would underwrite for the rest. The non-
slaveholding States would be compelled to observe the
 stipulations of the constitution in our favor, or abandon their
trade with us, or to take measures to coerce us, which would
throw on them the responsibility of dissolving the Union. Which
they would choose, I do not think doubtful. Their unbounded
avarice would, in the end, control them. Let a convention be
called—let it recommend to the slaveholding States to take the
course advised, giving, say one year's notice, before the acts of
the several States should go into effect, and the issue would
fairly be made up, and our safety and triumph certain."

This the only difficulty—the want of a co-operation of all the

Southern Atlantic States; and to surmount that, the indispensability
of a convention of the Southern States is fully declared. This was
going back to the starting point—to the year 1835—when Mr.
Calhoun first took up the slavery agitation in the Senate, and when a
convention of the slaveholding States was as much demanded then
as now, and that twelve years before the Wilmot Proviso—twelve
years before the Pennsylvania unfriendly legislation—twelve years
before the insult and outrage to the South, in not permitting them to
carry their local laws with them to the territories, for the protection
of their slave property. A call of a Southern convention was as much
demanded then as now; and such conventions often actually
attained: but without accomplishing the object of the prime mover.
No step could be got to be taken in those conventions towards
dividing and sectionalizing the States, and after a vain reliance upon
them for seventeen years, a new method has been fallen upon: and
this confidential letter from Mr. Calhoun to a member of the Alabama
legislature of 1847, has come to light, to furnish the key which
unlocks his whole system of slavery agitation which he commenced
in the year 1835. That system was to force issues upon the North
under the pretext of self-defence, and to sectionalize the South,
preparatory to disunion, through the instrumentality of sectional
conventions, composed wholly of delegates from the slaveholding
States. Failing in that scheme of accomplishing the purpose, a new
one was fallen upon, which will disclose itself in its proper place.
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com