Nick Coblentz

Security and Development: Building A Better Relationship

2012-01-16T11:21:00.000-06:00

Let's build a better relationship between security assessors and software developers. Instead, of having security teams act like an external, neutral audit group that simply finds problems and reports them, let's make security assessors problem solvers, advocates, and advisors!

Typically, assessors identify security defects, and then reports issues to the application development team. Defects may be accompanied by a best practice approach or description for remediating each vulnerability, but that advice often isn't customized for the relevant framework, language, or libraries being used in the software package. Assessments typically occur after specific milestones like a release or after an elapsed time period. I want to shake up these patterns!

First, let's assign a relationship, development team, and set of applications to each assessor within the security group. This assessor will partner with software developers and really get to know the application over time through repeated interaction and review. Next, let's give the assessors read only access to the source code repositories for each application they are assessing. Now, instead of providing security services (assessments, code reviews, architecture reviews, design reviews, etc.) once an application reaches a specific milestone, let's make the assessor responsible for guiding the team on a continuous basis. The assessor attends important meetings, gets to know the project goals, identifies and executes on security needs continuously, provides training, advice, and gets out in front of potential privacy, compliance, and security concerns while the application is still being designed and architected.

The organization as a whole should have specific security tools and activities that are required for all applications (may be a tiered approach based on an application's risk profile and valuation) identified in advance and the security assessor is responsible for setting up, configuring and running these tools and activities (often with cooperation of the development team). Let's assume that the organization uses a static code analysis tool to identify security defects in a software package. The tool is installed on a continuous integration server (automatically monitors code repositories, checks out, builds, and then assesses code for quality and security) and as new defects are found, the security assessor is notified. The security assessor is then responsible for reviewing and validating the findings (alternatively, a filter could be set up to notify developers of security issues already mastered and the assessor could receive only new issues). Once a finding is validated, the assessor develops an example code patch that would remediate the vulnerability. He or she then brings that solution to the software team, and provides a mini training session with the whole team covering: information about the vulnerability, the specific best practice used to remediate it, and then the code proposed to fix the issue. The team (security and development) discusses the cause, effect, and fix, and then the team as a whole agrees upon an appropriate secure coding standard for that vulnerability class (based on the code example above). Finally, the development team applies that standard for all instances of the issue in the application and uses it for developing similar code in the future.

This approach allows teams to identify and fix security defects quickly, it allows developers to focus on developing code rather than understanding security tools, and creates a relationship in which the security team brings solutions to the table rather than problems.

Taking it further: If the organization has a formalized secure software development process and a central repository for application security requirements, then the knowledge should be captured within this repository in the form of application security requirements and secure coding standards. These added requirements and secure coding standards should be evangelized to other software development teams to help them avoid similar vulnerabilities.

Related:
Turn Application Assessment Reports into Training Classes
Security Testing Roles - Expanding on Integrating Security Testing into the QA Process

Web Application Vulnerability Unit Testing Cheat Sheet (Capybara and Watir-WebDriver)

2011-11-30T08:00:00.000-06:00

For an example template for Watir-WebDriver/RSpec or Capybara Test Case, start here:

http://nickcoblentz.blogspot.com/2011/11/using-watir-webdriver-or-capybara-for.html

For common questions with Watir-WebDriver or Capybara, look here next:

http://watirwebdriver.com/web-elements/ (and the "advanced interactions" items)
https://github.com/jnicklas/capybara

Finally, refer to the cheat sheet below for issues I came across while trying to write test case for web application vulnerabilities:

Detect and Close JavaScript Alert Boxes:
Watir-WebDriver

begin
browser.driver.switch_to.alert.accept #raises an exception if no alert is present
puts 'alert box found'
rescue
puts 'alert box not found'
end

Capybara:
page.driver.browser.switch_to.alert.accept

Perform Arbitrary HTTP POST Requests:
Watir-WebDriver

Send Keyboard Commands:
Watir-WebDriver
browser.text_field(:name,/login/i).send_keys(:arrow_down)

Capybara:
page.find_field('login').native.send_keys(:arrow_down)

Search For Text/HTML Within a Nested Frame:
Watir-WebDriver

Returning Content From Javascript:
Watir-WebDriver
browser.execute_script(‘return “asdf”’) #=> returns “asdf” to ruby

Include JQuery:Watir-WebDriver

browser.execute_script(%q|var el = document.createElement("script");el.setAttribute("src","http://code.jquery.com/jquery-1.6.4.min.js");document.body.appendChild(el);|)

Return HTTP Headers:
Watir-WebDriver

Using Watir-WebDriver or Capybara For Web Application Vulnerability Unit Testing

2011-11-22T15:17:00.001-06:00

Back in October, I gave a Security B-Sides presentation filled with demos showing how to construct and execute unit tests for web application security vulnerabilities. The goal was to:

Allow QA teams or developers to execute unit tests to demonstrate that a web application vulnerability remains fixed 1 day, 1 week, 1 month, or even 1 year from the date it was remediated (For example, security unit tests run as part of a continuous integration process).
Provide a mechanism for security teams to demonstrate a vulnerability instance to web application stakeholders. One that can be run by the stakeholders themselves, as many times as needed, with little or no knowledge of security testing techniques.
Allow security testers to write testing tools or scripts that interact directly with the browser, eliminating many false positives occurring due to the inability to execute JavaScript or other similar browser dependent components.

The presentation slides and unit test scripts are available below. Before trying out the unit tests, make sure you have the OWASP Broken Web Application Virtual Machine downloaded and running. Next, install Ruby, Watir-WebDriver, RSpec, escape_utils, and Capybara.

To install everything on Windows, here's what I did:
1. Install Ruby (1.9.x) (http://rubyinstaller.org/downloads/)
2. Install Watir (http://watir.com/installation/#win)

Get an admin command prompt 
gem update --system 
gem install watir 
gem install watir-webdriver

3. Install RSpec and escape_utils

gem install rspec 
gem install escape_utils

4. Install Capybara
gem install capybara

To run the test cases, use the following commands:
rspec -f d "OWASP Broken WebApps RSpec.rb"
rspec -f d "OWASP Broken WebApps Capybara.rb"

Presentation Materials:

Security Testing Roles - Expanding on Integrating Security Testing into the QA Process

2011-10-13T15:57:00.000-05:00

If you haven't read my previous post: Integrating Security into the QA Process and/or listened to the podcast from Rafal Los: http://podcast.wh1t3rabbit.net/down-the-rabbithole-episode-3-qa-and-security-can-we-make-it-work-, do that first. The content below breaks down my thoughts on the type of security testing that can be integrated into each role (developer, QA, Security). This covers security testing, and does not include any other activities like threat modeling, architecture review, design review, following secure coding standards during development, etc.

Development Team:

Use an automated static code analysis tool (for example: Ounce, Fortify, or Veracode)
Perform peer code reviews
Construct and run unit/functional/automated tests for previously identified security issues using libraries like Watir/WatiN/Watij/Capybara/etc

QA Team:

Test security controls that can be broken down into positive, concrete tests with a clear start and end (may require step by step directions and training) -- possible focus mainly on controls that ALL application should have in place
Construct (or have developers construct) and run unit/functional/automated tests for previously identified security issues using libraries like Watir/WatiN/Watij/Capybara/etc (listed for both QA and Dev.)
Perform testing for business logic or domain specific vulnerabilities (a list of these business logic rules should be specified in the application's requirements)

Security Team (possibly a team within QA!?!):

Manually Perform negative testing and using penetration testing experience to identify issues
Perform automated static code analysis (for example: Ounce, Fortify, or Veracode)
Perform manual code review
Perform automated security scanning (for example: AppScan, Web Inspect, or Burp Suite)

I also want to emphasize that identifying a vulnerability through testing should ALWAYS result in the organization creating a new or correlating to an existing application security requirement (like a functional or business requirement) and an associated secure coding standard (specific code/configuration example and discussion showing how to accomplish the application security requirement in a particular development language, framework, and/or library). The goal is to proactively avoid vulnerabilities in the future, decreasing costs and improving security for all projects within the organization rather than for one specific application. Feeding solutions back into the requirements specification phase of software development will help accomplish this.

Integrating Security into the QA Process

2011-10-11T12:46:00.001-05:00

I just listened to the latest podcast from Rafal Los's site "Down the Rabbit Hole":
http://podcast.wh1t3rabbit.net/down-the-rabbithole-episode-3-qa-and-security-can-we-make-it-work-

On the show, they discuss integrating security testing into the QA process, which isn't terribly new, but what I got really excited about was the discussion about *how* to integrate it. Security testing is difficult for QA teams. Security testing requires specific skill sets and knowledge. QA teams don't know how to run automated security testing tools, have trouble interpreting the assessment results, and usually focus on testing defined requirements rather than having an open-ended mandate to look for security defects.

On the podcast, they recommend breaking security testing up and distributing it across the organization as much as possible. Security testing should be a normal part of developing and testing software. In regards to QA testing, define specific security tests, in a similar manner to the way functional or business requirements are tested, and provide those to the QA team. Step by step directions, training on a particular tool (like the web developer toolbar plugin for Firefox, not necessarily a static code analysis tool), or custom scripts may be required and included in these test definitions (use templates if possible). Link all of these security defect QA tests to functional or business requirements (this may require the organization to define new ones). Then, add these requirements back into the software development process, so they are included during the planning, design, or coding phases. Finally, provide secure coding standards that show step by step directions or specific code examples for accomplishing the functional or business requirements in the team's language, framework, library, or other software component.

Security B-Sides Kansas City Presentation

2011-10-04T10:59:00.000-05:00

Security B-Sides Kansas City is happening Wednesday, October 26, 2011. I will be presenting there at 10AM. The topic is using Watir-WebDriver (a browser automation framework/driver) and Ruby to perform web application security unit testing. While doing the research, I also got a chance to use another framework, Capybara, so I included examples from it as well. The presentation will mostly consist of demos. I will discuss what Watir-WebDriver is, alternate frameworks and languages to use, and how to apply them to web application security unit testing. Then, I will walk through specific examples/demos showing how to use the frameworks to exploit/unit test vulnerabilities in the OWASP Broken Web Applications Project/VMware image. The unit testing framework I chose is RSpec. I have demos ready for the following issues:

SQL Injection

error message based
matching contents of a union select over the application usernames/passwords

Cross-site Scripting

Reflected - URL Based
Reflected - Using a custom POST request
Stored

Autocomplete
Session Fixation
Open Redirect
Enumerating authorization/access controls
Information Disclosure through HTTP headers

After the presentation, I can provide anyone that asks with completed unit tests for all of the vulnerabilities listed above for both Ruby/Watir-WebDriver and Ruby/Capybara, using RSpec as the unit testing framework. To run these demos at home, simply download and run the OWASP Broken Web Application VMware image using VMware Player.

Potential BlackBerry Playbook Application Permissions Vulnerability - Need Help Confirming

2011-10-03T14:55:00.000-05:00

I'm posting some details about a potential BlackBerry Playbook application permissions vulnerability with the idea that others out there may help confirm and test the issue's existence. I can only take the exploit so far, and I need help from those with a BlackBerry AppWorld Vendor Account and a Playbook device (I have neither of these at the moment).

A completed exploit/application is available here: http://dl.dropbox.com/u/1132296/PermissionsTestModified.bar

Vulnerability Discussion

What I *think* I have found is a vulnerability that will allow an attacker to develop a BB Playbook application (think malware) with specific device permissions without those permissions being reported by App World. What I have discovered is when you compile a WebWorks SDK application, the SDK uses a config file containing permissions as an input, and compiles those permissions into a flash file. The flash file manages, fullfills, and grants access to device APIs like accessing the camera, accelerometers, or sensitive user/device information. I suspect that AppWorld determines the permissions for the application via that config file OR possibly a method call like getPermissions() in the flash file, but I have no way to confirm this. I can alter the config file so it shows zero permissions, but then deploy an application with full permissions on the BB Playbook simulator successfully. Now I need to confirm that AppWorld reports that no permissions are granted to the application despite the fact that these privileged APIs are being called successfully. If it is successful, It will tell me that AppWorld relies on the config file to notify users of application permissions (which means I can get arbitrary permissions without the user ever knowing).

If that first attempt is unsuccessful, then I have already successfully disassembled, altered, and reassembled parts of the flash file and reincluded it within the application, so its just a matter of discovering how to obfuscate those permissions from AppWorld. Most, if not all, the permissions enforcement occurs in the compiled flash file rather than by the underlying operating system itself.

The specific help I need is in publishing the application to AppWorld, observing the permissions reported for the application via AppWorld, and observing the permissions reported for the application via the Permissions Module on the Playbook control panel, and then running the application on a Playbook itself (rather than the simulator, which works just fine, but doesn't report permissions at all). I don't own a BB Playbook and I don't currently have a Vendor account, so it is difficult to confirm whether this issue really exists.

If you have a BB AppWorld Vendor Account and a BB Playbook that you can confirm my results on, please read the details below and publish your results.

Instructions

First, install all the prerequisites needed to compile and deploy a BB WebWorks SDK application. For a walk through, take a look at this guidance: http://us.blackberry.com/developers/tablet/webworks.jsp

Next, we will create a very simple WebWorks App that uses a few privileged API calls (specifically the Blackberry.app API: http://www.blackberry.com/developers/docs/webworks/api/blackberry.app.html). We will use the example provided in the API documentation to create an index.html page:

Then, add the JQuery libraries referenced by the index.html page to the /js folder.

Now, we will create two configuration files, one containing the proper permissions and one without any permissions. config.xml should read:

config2.xml:

Compile the application into a .bar file as you would any other WebWorks application. First create a zip archive at the root level of the application, then run the following command:

"c:\Program Files (x86)\Research In Motion\BlackBerry WebWorks SDK for TabletOS 2.1.0.6\bbwp\bbwp.exe" PermissionsTest.zip -d

In the /bin directory, a PermissionsTest.bar file will be created. Unzip this file (its just a zip file containing the compiled flash file and html, JavaScript, and XML files. Open the /bin/PermissionsTest/META-INF/MANIFEST.MF file. There will be two lines we will modify. They are (the SHA-512-Digest value will differ):

Archive-Asset-Name: air/config.xmlArchive-Asset-SHA-512-Digest: 9x6Jp-WRWEV14A0DGdO7rIIXxEB7V-Ya6Ke1pRnM9oeckJB6GzS9EqzoDosXyaUEEaLDebxE6o36UalIqtv2gQ

Archive-Asset-Name: air/config2.xmlArchive-Asset-SHA-512-Digest: Y5hA0NxFXOCHpfy5utM-9oMWG5elciLxKNWl0AcU4azyXWDBOrq6v4tw9cU0coG3jXzWqg4Od3OtZsEcqxNLwA

Delete the lines for config.xml, then rename config2.xml to config.xml

Next, go to the /bin/PermissionsTest/air/ directory and delete "config.xml", and rename "config2.xml" to "config.xml"

Go back to the /bin/PermissionsTest directory and make a new zip archive. Change the file extension from ".zip" to ".bar".

Deploy the application to the simulator (or AppWorld):

"c:\Program Files (x86)\Research In Motion\BlackBerry WebWorks SDK for TabletOS 2.1.0.6\bbwp\blackberry-tablet-sdk\bin\blackberry-deploy.bat" -installApp -device <device ip here> -package bin\PermissionsTestModified.bar -password <simulator device password>

When you open the application, and click "Populate - APP" it should retrieve the author and title of the application (which require privileged API access).

So Why does this work?

Permissions seem to be enforced by the Adobe AIR application executable rather than the protected operating system itself. if you decompile the swf file generated by the compilation process, you will see the following interesting code fragments:

public static const values:Object={"configXML":"config.xml", "version":"1.0.0", "content":"index.html", "author":"Nick Coblentz", "description":"This application tests whether privileged APIs can be called without AppWorld reporting those permissions to the user.", "name":"Permissions Test", "foregroundSource":"index.html", "hasMultiAccess":true, "onFirstLaunch":false, "onRemotePageLoad":false, "onLocalPageLoad":false, "debugEnabled":true, "accessList":new Array(new webworks.access.Access(webworks.config.ConfigConstants.WIDGET_LOCAL_DOMAIN, true, new Array(new webworks.access.Feature("blackberry.app", true, "", null)))), "widgetExtensions...lots more...

and the isFeatureAllowed() method in webworks.config.ConfigData which is used by webworks.FunctionBroker to determine whether to service JavaScript JSON requests for privileged API access.

Request For Help

If anyone chooses to lend a hand, I would welcome help further understanding the inner workings of the generated flash file, validation that the vulnerability exists, and validation of the permissions reported by AppWorld and the Playbook device itself. Feel free to add comments on the blog or email me directly.

OWASP AppSec Ireland and DC

2010-09-10T10:54:00.001-05:00

OWASP AppSec Ireland is a week away! If you happen to be in Dublin, Ireland next Friday, come by and say "Hi!" I will be presenting "Microsoft's Security Development Lifecycle for Agile Development". More information is available here:

http://www.owasp.org/index.php/OWASP_IRELAND_2010#Agenda_and_Presentations_-_September_17

I was also accepted to speak at OWASP AppSec DC on November 10th or 11th. This will be the first time I will give the SDL-Agile presentation at a conference in the United States! The conference home page is: http://www.owasp.org/index.php/OWASP_AppSec_DC_2010

Rails 3 HTML Encodes by Default

2010-08-30T08:27:00.002-05:00

Rails 3 came out recently, and the developers made a significant change that really improves the security posture of Rails 3. They really embraced the "secure by default" security principle in their efforts to eliminate cross-site scripting. Previously, unsafe user data had to be explicitly HTML encoded in order to avoid cross-site scripting. This was done using the "h" tag. For example:
<%= h(@unsafe_user_input) %>

In Rails 3, the default is to automatically HTML encode. The "h" tag is no longer necessary. Instead, developers must go out of their way to output HTML content to the page using the "raw" tag. For example:
<%= raw(@unsafe_user_input) %>

I think the Rails developers took a really strong stance on this issue and it will result in a safer Ruby on Rails ecosystem.

Please see the video below for more details:
http://rubyonrails.org/screencasts/rails3/xss-ujs

There is also a really great Rails security guide found here:
http://guides.rubyonrails.org/security.html

OWASP AppSec Research 2010 Stockholm Conference Videos Posted!

2010-07-23T09:53:00.001-05:00

The presentation videos from the OWASP AppSec Research 2010 Conference in Stockholm, Sweden are now available!

My Presentation slides can be found here:

http://www.owasp.org/images/4/44/OWASP_AppSec_Research_2010_Microsoft_SDL_Agile_by_Coblentz.pdf

A video of the presentation is also available:

http://owasp.blip.tv/file/3918259/

The rest of the videos and presentation slides can be found here:

Martin Holst Swende and Alan Davidson, members of the organizing committee, took pictures at the OWASP AppSec Research 2010 Conference. Those pictures can be found here:

I will be giving this presentation again at the OWASP AppSec Ireleand 2010 Conference on September 17, 2010 (http://www.owasp.org/index.php/OWASP_IRELAND_2010) .

OWASP AppSec Research 2010 Pictures

2010-06-24T15:23:00.001-05:00

The OWASP AppSec Research 2010 Conference in Stockholm, Sweden ended today. I took a quite a few pictures and I thought I would post a couple of them. Please enjoy!

Aula Magna (Conference Venue)

Track 1

Day 1 Keynote with Chris Evans, Google

Day 2 Keynote with Steve Lipner, Microsoft

Gala Dinner at Stockholm City Hall

Conference Closing Remarks and Thanks

I'm Presenting at OWASP AppSec Research 2010 Conference

2010-05-12T16:52:00.002-05:00

The OWASP AppSec Research 2010 conference is being held on June 23rd and 24th 2010 in Stockholm, Sweden. I will be speaking on the 24th at 11:10 AM on "Microsoft's Security Development Lifecycle for Agile Development". Here is a link to the schedule for June 24th:
http://www.owasp.org/index.php/OWASP_AppSec_Research_2010_-_Stockholm,_Sweden#tab=June_24

I hope to see lots of people there!

.NET User Group Presentation - Microsoft SDL-Agile

2010-03-24T09:40:00.001-05:00

I had a great time giving my Microsoft SDL-Agile v2 presentation last night at the Kansas City .NET User Group Meeting. Several people asked for the slides, so I made them available as a PDF document here: Microsoft SDL-Agile Presentation - Nick Coblentz V2 2010-03-23.pdf

Many also wanted links to the tools I mentioned during the presentation. Here is a list of those tools:

Finally, here are links to the code used to demonstrate the Web Protection Library:

Please feel free to email me with any questions or comments about the presentation.

Reducing Information Disclosure in WCF Data Services

2010-02-24T09:00:00.025-06:00

Previously, I wrote an article titled "Reducing Information Disclosure in ASP.NET Web Services". The article identified steps developers can take to eliminate detailed error messages, stack traces, web service description pages, and WSDLs from their production applications. This article will offer similar recommendations for WCF Data Services. Since this article builds of the previous one, I will not repeat the background information.

Reference WCF Service
We will use the following WCF service as a starting point.

Here is a successful SOAP request.

The WCF Help Page and WSDL are accessible as shown below.

The following two errors occur when parameters are omitted in the web service call or when we try to divide by zero.

ASP.NET Custom Errors: No Help At All
Unlike ASP.NET web services, exception handling in WCF data services is not the least bit affected by enabling custom errors. When custom errors are enabled, full stack traces, local file paths, and other information is returned to the consumer.

Explicit Try/Catch Blocks: 100% Effective, But What If You Miss One
Try/Catch blocks are just as effective as in ASP.NET Web Services. Here's the code.

And the result.

As stated in the ASP.NET Web Services article, there is always a chance that we could miss a try/catch block. We need some sort of backup solution to catch any exceptions that we miss.

includeExceptionDetailInFaults="false": A Great Backup to Try/Catch Blocks
In WCF Data Services, this functionality seems more complete and it is just as easy to implement as in the last article. Simply set the "includeExceptionDetailInFaults" attribute to "false" in the "serviceDebug" XML element of the Web.config file.

Stack traces and other detailed error information are now suppressed.

Removing the WSDL and WCF Help Pages
Help pages and the WSDL can easily be removed for WCF services. The "serviceMetadata" and "serviceDebug" XML elements in the Web.config file have attributes to specifically control these items.

When the appropriate attributes are set to "false", the help page and the WSDL show up as blank pages.

Once this change has been made, it will be necessary to communicate WSDLs or web service signatures with partners through some other channel.

WCF Metadata Exchange (MEX)
There is one additional issue to address with WCF Data Services, and that is to disable the Metadata Exchange (MEX) endpoint. Clients and attackers can query MEX endpoints to learn about web service signatures and configuration. For more information about MEX, see the following articles:

An example HTTP request and response used to query a MEX endpoint is shown below.

Additionally, an attacker can utilize the WCF Test Client to capture this data and query the service.

This behavior can be disabled by removing the MEX end-point. In the Web.Config file below, the end-point is commented out.

After the configuration change, the MEX endpoint is no longer accessible.

Reducing Information Disclosure in ASP.NET Web Services

2010-02-10T09:00:00.004-06:00

*Note: This article does not directly apply to WCF Data Services

Many applications use external web services to allow partners, WPF/Silverlight applications, cloud components, or other entities to access information and functionality. Trusted parties can use SOAP, REST, or AJAX requests to communicate with ASP.NET Web Service end-points.

Since standard protocols are used to connect with these components, malicious users can also issue requests to your web services. In some cases, web services provide detailed information regarding the method calls and parameters available, as well as detailed error messages for failed attacks. It's important to reduce the amount of information provided to attackers by ASP.NET web services.

Reference Web Service
First, let's start with a basic ASP.NET Web Service. The code is provided below.

This web service accepts a dividend and a divisor and it returns the quotient. Since this is a simple demonstration, the code does not include any functionality or data that an attacker would likely target, but the concepts that are demonstrated still apply.

If we run this application and visit the Math.asmx page, a description page is displayed. The description page lists all the web service methods, parameters, and even provides example SOAP requests for calling the methods. Since I am accessing the service locally, it also provides an HTML form to test the functionality. Depending on the settings in the Web.Config file, this form may or may not be available to external users.

In addition to the description page, the WSDL document is also accessible.

A client can call this service using a SOAP or REST request, as shown below.

By default, the application displays detailed error messages. Two example exceptions are shown below. The first exception is due to a divide by zero condition; the second is due to missing parameter values in the SOAP request.

ASP.NET Custom Errors: 80% Effective

ASP.NET applications have a Custom Error Handler that can be used to control the detail level of error messages provided to clients. It is very easy to configure the Custom Error Handler in the Web.Config file. See the "customErrors" XML element in the screenshot below.

After enabling Custom Error Handling, the error messages for the divide by zero condition shows much less detail. We have eliminated the stack trace information; however the title of the error is still present. In a real world web service, SQL Exceptions such as "Unclosed Quotation Mark" would still be shown. Simply enabling Custom Errors is not enough to resolve this information disclosure issue.

Explicit Try/Catch Blocks: 100% Effective, But What If You Miss One
It's considered a best practice to catch and correctly handle any exceptions that occur within code. This technique is also important for preventing detailed error messages from reaching the client. Consider the code below.

In this sample, we catch the divide by zero exception and then just return 0. In a real world application, a much more robust solution should probably be implemented. This new code results in no business functionality related exception being shown the user.

While this solution is effective at preventing verbose error messages from reaching the client, there are cases when a try/catch block could be missed. One could wrap all code in a try/catch block for the generic Exception class, but this is not a very elegant solution.

Suppress Returning Exceptions: A Great Backup to Try/Catch Blocks
Wouldn't it be nice if there was a "customErrors" style solution for web services? The "diagnostics" XML element within the web services section of the ASP.NET Web.Config file can provide this type of functionality.

This configuration change results in the following limited error message for the divide by zero condition.

This solution is very effective; however there is one caveat. Both explicit try/catch blocks and the Web.Config change still will not control error conditions that occur due to missing parameters or incorrect value types.

This solution provides a great catch all for situations where an explicit try/catch block may be missed.

Removing the WSDL and Service Description Pages
A quick Web.Config change can be used to disable WSDLs and description pages.

Once this change has been made, it will be necessary to communicate WSDLs or web service signatures with partners through some other channel.

How Often Should I Reassess My Web Applications?

2010-01-20T11:37:00.001-06:00

There are a couple approaches for determining when an application should be undergo a security assessment. First, organizations often require new tests after a fixed period of time. This period of time may vary based on the risk level the organization has attributed to each application or application type. It's common for organizations to conduct security assessments of high and medium risk applications every six months to one year. For low risk applications, the time period is often a year to two years. The risk level of an application is often determined based on the type of data and functionality within the application. For example, an Internet facing application that handles credit card transactions would be considered high risk; while an application that simply provides product information and is not subject to regulatory, compliance, or legal requirements may be low risk. Periodic assessments usually supplement the next two approaches.

The second approach is associated with major changes implemented in the application. There are a variety of changes that should trigger a new application assessment. Any changes to a security mechanism should undergo validation. Security mechanisms usually include things like authentication processes, authorization controls, session management features, and data validation and encoding components (think cross-site scripting, SQL injection, etc.). Changes that add or modify a feature in the application should trigger a retest based on the risk level of the application and the sensitivity of data or functionality that the change effects. So, a new feature that adds an “about” tab to a website probably doesn’t need to undergo rigorous security testing; however, a new feature that collects users’ social security numbers absolutely should undergo testing (including evaluation whether collection of this PII complies with the organization’s policies, that there is a need to know for this sensitive data, that the sensitive data is adequately protected at rest and in transit, and that only authorized, authenticated parties can reach this data). Organization’s typically set up criteria and standards around PII, credit card information, and other sensitive data types that automatically trigger a reassessment when an application change related to those data types occurs.

The third approach is to use application security testing as a security gate within an organization’s development process. In this case, specific application types or risk levels would require an assessment before they can be deployed to production. This is usually one of the final steps in a secure software development process and acts as a sanity check or a process improvement opportunity rather than a catch-all for security issues. These types of tests are often highly targeted and would not encompass an assessment of the whole application; instead the security assessment would focus on high risk, new, or updated components introduced in the application.

Previously, I wrote an ISSA article, Titled “Web Application Security Portfolios”, which covered some of this detail. An expanded version of this article can be found in my post here. The article discusses ideas around managing portfolios for each application within an organization, identifying data types and compliance requirements, and tracking security activities.

Microsoft SDL-Agile Presentation Slides

2009-12-10T22:17:00.005-06:00

I wanted to thank everyone who came to the OWASP Kansas City Chapter meeting tonight. I had fun presenting.

A copy of the slides are available here: OWASP Kansas City, Microsoft SDL-Agile Presentation

Unfortunately the animations don't work in the PDF version, but I would be happy to present at other meetings, user groups, or for a group of developers/managers within a company. If you are interested, please feel free to email me. My contact information is listed in the sidebar of this blog.

OWASP Presentation on Dec. 10: Microsoft SDL-Agile

2009-11-18T13:02:00.004-06:00

I will be giving an OWASP presentation on December 10th over the Microsoft Security Development Lifecycle for Agile Development. The presentation will be about 45 minutes and is scheduled to begin at 6PM in Regnier Center Room 270 at JCCC.

Here is the original announcement from the OWASP Kansas City List: https://lists.owasp.org/pipermail/owasp-kansascity/2009-November/000085.html

Microsoft SDL for Agile Development

2009-11-10T15:11:00.006-06:00

Microsoft recently released a document describing how to apply the SDL process to Agile development. Take a look at their blog post or download the document here.

Observed Secure Software Development Stages

2009-10-26T10:00:00.001-05:00

A secure software development process cannot be built overnight. Organizations gradually adopt security activities based on factors like culture, customer demand, regulations, budget, and security incidents. Each organization adds security practices at different rates; however, most organizations do so in a predictable order. This common order is a reflection of how businesses today use trial and error to find an appropriate set of processes and practices to grow a secure development process.

This order can be broken down into six stages. While few organizations fit exactly within one stage or another, this model can be used to facilitate discussions about an organization’s current progress. The model does not seek to validate whether the six stages constitute an appropriate secure software development roadmap, instead; it simply describes a common progression observed in organizations today. Models like the Software Assurance Maturity Model (SAMM) and Building Security In Maturity Model (BSIMM) are more appropriate models for determining the proper direction of an organization’s secure development process.

Stage 1: Focus on Functionality

Initially, organizations are fairly ignorant of secure development practices. Computer science curriculum often does not include a class on security best practices or ways prevent cross-site scripting vulnerabilities. Developers are taught how to write code to satisfy business requirements.

Secure software development also isn’t high on executives’ list of priorities. Their focus is on producing innovative products or services, being first to market, and making net income goals.

Security usually does not become a priority until an incident occurs, whether a competitor has a data breach or the organization itself is hacked. Once this tipping point occurs, security dollars quickly become available. Organizations spend their new security budget on third-party application assessments, which provide an insight into the security posture of information technology assets.

Stage 2: Assessments Alone

Once an organization starts performing security assessments in response to a breach, it typically extends this activity for use as an approval mechanism. The organization requires sensitive or business critical applications to be assessed prior to new releases being deployed to production. This approach greatly reduces the number and severity of vulnerabilities in external facing applications; however, it doesn’t identify security weaknesses until after the application is fully developed.

Vulnerabilities that highlight a systemic weakness or architectural flaw will often result in project delays and unanticipated costs. Additionally, this approach does not train developers to implement code securely during the initial development stage.

After performing assessments as the only software security activity, the organization eventually realizes that a proactive approach is needed. They determine that issues should be identified early in the development process and opt for purchasing automated code review or penetration testing tools.

Stage 3: Ad-hoc Use of Security Tools and Activities

After providing automated code review or penetration testing tools to developers, organizations expect all their application security challenges to be solved. They tell developers that they need to run the tool on their code and fix all the issues. The organization’s goal is to have production ready software at the conclusion of the development process. The actual results of this approach vary.

Development groups composed of security savvy members usually see an overall reduction in vulnerabilities. The other development groups may only see a moderate impact. There are a variety of reasons this happens. The primary reason is that the tools can identify plenty of problems, but the developers don’t have the knowledge necessary to understand all the risks or to apply security best practice recommendations. Other challenges include the inability of automated tools to find business logic, authorization, and authentication flaws; inconsistent company procedures and checkpoints associated with running the tools; and no minimum standard set for acceptable risk levels.

Organizations also may adopt security activities such as threat modeling, secure requirements specification, and design reviews. These activities produce greater awareness of security issues facing applications, but the developers’ still lack the knowledge and experience necessary to really take advantage of these proactive security activities.

Stage 4: Application Security Training

The next logical step for organizations is to provide application security training to development groups. This comes in the form of in person classes, on-boarding training, and annual refreshers. The class content often includes a general background in application security, introduction to common vulnerabilities and attacks, and best practice approaches for eliminating preventing and remediating issues.

Application security training greatly improves developers’ ability to succeed at the organizations continued use of automated tools and third party assessments. Developers gain a common language to discuss application security concerns, can understand and address vulnerabilities in a timely manner, and the training can inspire developers to pursue additional research.

One aspect most organizations leave out is reinforcing and supplementing training with internal resources. Many developers receive training once a year in application security. After six months, most of the knowledge gained during the class is forgotten.

Stage 5: Creation of Resources, Formal Policies, Procedures and Standards

In order to ensure consistent use of security tools and activities, organizations choose to formalize the policies, procedures, and standards developed over the previous four stages. Criteria is created for evaluating the sensitivity or importance of applications, security activities are formally required for each of these categories, and security gates are put in place to ensure a minimum standard of security is met before software advances in the development process.

An internal application security portal is also created to make these policies and additional resources available to developers. These resources communicate information about standardized methods for addressing vulnerabilities in code, approved development languages and frameworks, and internally developed secure libraries and architectures.

Ultimately, this results in the elimination of ad-hoc security activities and promotes consistent development of applications with fewer security vulnerabilities.

Stage 6: Secure Software Assurance

In the last stage, organizations tailor security activities and requirements to satisfy business goals and leverage efforts as a competitive advantage. Before an application is developed, a set of security requirements is established. For each security activity, the organization defines a test procedure and criteria for determining whether the application passes or fails the security requirement. Test results are recorded and reported across the application’s lifetime to form an overall picture of the application’s security posture.

Turn Application Assessment Reports into Training Classes

2009-10-01T15:06:00.010-05:00

So you had a third party application assessment and you have a report 10 miles long. There are cross-site scripting, SQL injection, authentication, authorization, and every other kind of vulnerability under the sun listed. Your development team gears up and remediates issues, often using trial and error (patch, retest, pray, and repeat) to fix issues over several iterations. Eventually, all the vulnerabilities have been addressed successfully and you file the report away forever...

Stop Right There! There's an opportunity to use a real application within your organization to train developers to write secure code THE FIRST TIME! Here's how:

Taking the Time to Analyze Root Causes and Develop Standards

Now that the fire is out (the issues are fixed), let's take some time to understand how the vulnerabilities were created in the first place. Was it a result of missing output encoding practices, inconsistent page-level access controls, or some other issue? Gather a list of root causes that resulted in the identified weakness.

Next, use security experts or online resources, like OWASP, to find security best practice solutions for eliminating these vulnerabilities. Some great examples are the OWASP XSS Prevention Cheat Sheet or the OWASP SQL Injection Prevention Cheat Sheet. Finally, create a centralized application security portal or wiki that developers can access and add these root causes and best practice solutions as official company standards.

Bullet Points:

Create a centralized application security portal or wiki
As you analyze root causes and find security best practice approaches to fix them, add them as standards to the portal

Archive the Vulnerable Application Code for Later Use

After completing the third party assessment, you now possess real world vulnerability examples and a report that lists each issue, including the page and parameters vulnerable and a guide for exploiting them. This report and the vulnerable application will be a great learning tool to be leveraged later. Archive the vulnerable application code and any other related components. Make sure it is possible to restore this application to a working state within a test environment at a later date.

Bullet Points:

Archive the application and related components to be deployed within a test environment at a later date

Conduct Developer Training

In the weeks before hosting a training course, generate developer interest by deploying the vulnerable application within a well controlled, internal, isolated, secure... you get the idea... test environment. Send application URLs and credentials to developers and tell them what classes of vulnerabilities can be found (refer to your assessment report). Encourage developers to test and discover security issues individually until the training class.

In the training class, go through each vulnerability class or root cause with developers. Demonstrate application security attacks against the weaknesses using the vulnerable application deployed to the test environment as a real world example. Once you have gone through each vulnerability type, ask developers to discuss other areas of the application they identified as vulnerable during the preceding weeks. After the discussion, have developers break up into groups to find any remaining issues. Give hints as the number of remaining vulnerabilities dwindles.

Once all the issues have been found by developers or demonstrated by the instructor, ask developers for methods of addressing each vulnerability class. Intentionally choose suggestions that are missing key security best practice concepts. Have developers come up to the presentation computer and code solutions on the spot; then, discuss reasons why the solution is flawed, and prove it with an example attack.

After going through a few proposed solutions, discuss the root cause that lead to the security weakness. Provide the best practice solution for eliminating the issue and preventing it in future code. Finally, show developers where they can access this company standard on the internal portal or wiki and have a developer implement the solution to fix the vulnerability on the spot.

Bullet Points:

Generate developer interest in the training course by allowing them to hack the vulnerable application
During the training course, discuss vulnerability classes, root causes, incorrect remediation solutions, security best practice based recommendations, and where to find company standards

Conclusion

Turning application security reports into company security standards and training courses is a great way to increase the return on investment for third party assessments. The suggestions discussed in the article above will greatly help developers succeed at writing secure code in future web applications. The process also uses meaningful real world applications to demonstrate the concepts and promote interest.

Some of these steps may require security savvy developers or security experts. If you would like assistance developing training courses, identifying root causes, or documenting security standards, please feel free to send me an email. I can be contacted at <My First Name>.<My Last Name>@gmail.com.

AT&T Acquires VeriSign's Global Security Consulting Business

2009-10-01T12:08:00.004-05:00

We've been acquired! I am now an AT&T employee. Check out the press release here: http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=27183.

For a list of professional services offered related to security, see this page: http://www.corp.att.com/consulting/security/ (especially Application Security Services).

Using Microsoft's AntiXSS Library 3.1

2009-09-19T12:35:00.015-05:00

Microsoft recently released the AntiXSS Library Version 3.1. This library provides methods to output encode or escape untrusted user input within ASP.NET pages. The OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet provides a significant amount of detail regarding theory and proper use of output encoding methods. The examples provided in this OWASP resource relate to the ESAPI library for Java and do not provide equivalent method calls for Microsoft's AntiXSS Library.

The sections below are an attempt to provide one-to-one mappings of the ESAPI Encoder calls and the AntiXSS calls needed to satisfy each section of the OWASP XSS Prevention Cheat Sheet.

Setup
Version 3.1 of the AntiXSS library can be obtained at the following URL:
http://www.microsoft.com/downloads/details.aspx?familyid=051EE83C-5CCF-48ED-8463-02F56A6BFC09&displaylang=en

By default, the installer places files in the "C:\Program Files\Microsoft Information Security\Microsoft Anti-Cross Site Scripting Library v3.1\" directory.

In Visual Studio, developers can add a reference to the AntiXSS Library by selecting the DLL located at "C:\<AntiXSS Library Base Directory>\Library\AntiXSSLibrary.dll".

Help files, complete with examples and theory, are located at "C:\<AntiXSS Library Base Directory>\Help\Anti-XSS_Library_Help.chm".

Usage
The following sections should map rules and OWASP ESAPI Encoder calls listed in the XSS Prevention Cheat Sheet to Microsoft AntiXSS Library Calls.

Rule #0: Never Insert Untrusted Data Except in Allowed Locations
This rule holds true as described by the Cheat Sheet. No mapping is required for the AntiXSS Library.

Rule #1: HTML Escape Before Inserting Untrusted Data into HTML Element Content
ESAPI Encoder Example:
String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );

AntiXSS Equivalent:
string safe = Microsoft.Security.Application.AntiXss.HtmlEncode( Request.QueryString[ "input" ] );

Rule #2: Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
ESAPI Encoder Example:
String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) );

AntiXSS Equivalent:
string safe = Microsoft.Security.Application.AntiXss.HtmlAttributeEncode( Request.QueryString[ "input" ] );

Rule #3: JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values
ESAPI Encoder Example:
String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

AntiXSS Equivalent:
string safe = Microsoft.Security.Application.AntiXss.JavaScriptEncode( Request.QueryString[ "input" ] );

Rule #4: CSS Escape Before Inserting Untrusted Data into HTML Style Property Values
ESAPI Encoder Example:
String safe = ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) );

AntiXSS Equivalent:
No direct equivalent

Flash Remoting Support in Burp Suite Pro

2009-08-28T10:00:00.003-05:00

Assessing applications that utilize flash remoting calls often require tools to analyze, manipulate, and replay requests. These tools are required because flash remoting request and response payloads are encoded using the Action Message Format.

Previously, I have used Deblaze and Charles Proxy to support these needs. On August 12, a new version of Burp Suite Pro was released. This version allows AMF messages to be encoded and decoded in the proxy, repeater, and other tabs (except Burp Intruder). Burp Scanner also supports placing attack payloads in flash remoting calls.

Amazon EC2 and PCI Compliance

2009-08-12T21:44:00.003-05:00

I saw a very informative forum post regarding Amazon's position on EC2 and S3 PCI compliance via a twitter update from @beaker (http://twitter.com/Beaker/statuses/3277444460). The post states merchants can not achieve level 1 PCI compliance within Amazon's cloud infrastructure, because Amazon will not allow customers to perform on-site assessments. Amazon recommends using their Flixible Payments Service to successfully handle credit card data within their cloud. Mosso, now "Rackspace Cloud", took a similar approach as discussed in my March 2009 blog post.

Vulnerability Tracking, Workflow, and Metrics With Redmine

2009-07-22T08:00:00.002-05:00

This article was inspired by real processes and software implemented in a client's environment. This client has a very proactive approach to application security. I would love to give specific attribution to some of these ideas, but I am not permitted in this case.

A functional defect is typically a set of undesirable behavior associated with an application feature. A security vulnerability (security bug) consists of undesirable behavior that weakens the application's ability to resist attacks or protect data. In terms of issue tracking and remediation, a security bug is really just a specific type of functional bug. This is apparent when you consider the basic workflow for a functional defect:

A developer or user reports a defect.
The project manager assigns the defect to a developer.
The developer implements code to resolve the issue.
The quality assurance team verifies that the implemented code successfully resolved the issue.
The project manager or team provides communication to executives, clients, or other entities regarding the successful resolution of the issue.
The issue is archived for use in metrics or other statistical analysis.

The workflow for a security bug contains the same steps but differs in the roles associated with each step. A security bug may require interaction or approval from security managers or security assessors in addition to developers and project managers.

Development teams already use bug tracking software during development, why not utilize the same systems for tracking security vulnerabilities? Project team's familiarity with the software and process will make it considerably easier to collaborate on remediation efforts. Additionally, most organizations already have methods of collecting metrics about software defects. These metrics can be extended to include vulnerabilities.

In order to effectively track security vulnerabilities, a centralized, web-based bug tracking system needs to support the following features:

Custom workflows per issue type
Custom fields within bug items
Roles and privileges controlling users' ability to change the status of security bugs

After a little research, I identified a bug tracking system called Redmine that satisfies all these requirements and more. In Redmine, I was able to create an issue type called "Vulnerability" and associated a specific workflow.

The diagram below illustrates the custom workflow, roles, and purpose of each step. This workflow can be created in Redmine and each transition can be associated with specific roles.

Since the software supports custom fields within issue items, a security assessor can enter additional vulnerability information such as:

The vulnerability category
Whether the issue has a security impact
Whether the issue has a privacy impact
Whether the issue has a compliance impact
Which group identified the issue
Whether the item was identified by an automated or manual process
Which activity was used to identify issues

Once many of these issues have been reported across an organization, this information can be used to evaluate the effectiveness of tools, processes, or security activities used throughout the development process. An example of a Vulnerability item being created in Redmine is shown in the screenshot below.

In addition to tracking vulnerabilities, this system could also be used to manage requests and the workflow associated with security services performed by an internal security team. Organizations often may utilize security teams to assist in specifying security, privacy and compliance requirements or to perform activities like penetration testing and code review. A custom workflow can be created in Redmine to handle this issue type as well.

Here is an example of a security service request in Redmine:

Appendix

Custom Fields:

Security Activities Custom Field:

Vulnerability Identification Method Source Custom Field:

Vulnerability Identification Method Custom Field:

Vulnerability Identified By Custom Field:

Vulnerability Category Custom Field:

Internal AppSec Portals: Resources

2009-07-01T19:34:00.047-05:00

Attribution:
Many of these ideas build on Pravir Chandra's Software Assurance Maturity Model (Version 1.0) and the Building Security In Maturity Model by Gary McGraw, Brian Chess, and Sammy Migues. Both works are licensed under the Creative Commons Attribution-Share Alike 3.0 License.

This article was also heavily influenced by Microsoft's SDL process.

The next several blog entries will cover my current project: providing a template or starting point for organization's internal application security portal. This post is the second of many to come.

Previous Internal AppSec Portals Posts:
Introduction

This post will cover providing application security resources for developers, including

Policies
Guidance
Requirements
Vulnerabilities
and External Resources

The following image is a screenshot of the table of contents for my TikiWiki Secure Software Assurance Resources structure. As discussed in the previous post, a Wiki is a great way to document application security resources, because it allows for constant, collaborative updates and can link and organize information in user friendly way. I recommend providing the resources discussed in this post in a similar format for project teams.

Goals
The purpose behind this set of resources is to provide all the information a developer needs to write secure code. Developers cannot be expected to pull secure code out of the air. Guidelines, coding standards, and security requirements must be spelled out to ensure everyone understands their responsibilities and the organization's expectations.

Additionally, developers MUST be provided with security awareness training AND training against this material.

Policies
Security Policies
Most organizations define a set of security policies that govern acceptable use of information systems, methods for labeling and handling confidential data, and procedures for addressing policy violations. These same concepts should be extended to cover application security, compliance, and privacy policies.

Security policies should express the organization's dedication to the topics below. These topics do not necessarily have to define the process or implementation of each policy area, only statements mandating their use.

Mandatory, periodic application security training
Adherence to application security guidance and coding standards
Use of a formal risk management process
Risk categorization of data and applications
Creation and maintenance of application security portfolios
Use of approved secure development processes
Dedication to meeting regulatory and compliance standards in each application project
Inclusion and validation of security, privacy, and compliance requirements throughout the development process
Establishment of a minimum level of assurance for application security, privacy, and compliance

Privacy Policies
In addition to security policies, organizations should maintain policies governing how personally identifiable information such as social security numbers, account numbers, or other data is handled. These policies should send a clear message to project teams that protecting users' private data is important. These policies should cover topics such as:

Identification and categorization of private data
Collection, storage, and transmission of private data
Inclusion and validation of privacy requirements during the development process
Establishment of a minimum level of assurance for privacy data

Microsoft has released a great deal of resources on privacy related policies, requirements and process. Those resources can be found below.

Microsoft's Privacy Guidelines for Developing Software Products and Services
Microsoft SDL Privacy Questionnaire
Microsoft SDL Privacy Requirements
Microsoft SDL Privacy At A Glance

Compliance Policies
There are a wide variety of compliance and regulatory standards that apply to organizations, data, and functionality. Project teams cannot spend all of their time researching these standards. At the organization level, compliance standards should be identified and a process should be created to assist developers in determining which regulations apply to their project. Compliance policies should include the following topics:

Identification of compliance and regulatory standards
Process for determining standards that apply to each software project
Inclusion and validation of compliance requirements during the development process
Establishment of a minimum level of assurance for software compliance

Guidance
Organizations should collect and publish internal guidance to be consumed by project teams. Guidance should not only include secure coding standards, but also approved frameworks, security services, architectures, and environments. These items should be provided in a way that clearly communicates approaches or code that is approved, an organization standard, or unapproved.

Approved Libraries and Frameworks
Software can be developed in a variety of languages and often includes external third party libraries. ASP.NET applications often include libraries such as ASP.NET MVC and Microsoft's AntiXSS library. Java applications may include Struts, Spring, Hibernate, Velocity, and many others. Additionally, developers may want to develop software in PHP, Python, Ruby, Perl, and other languages.

Organizations must communicate which of these languages and frameworks are approved for use in software projects. Guidance should start with a simple list of languages and frameworks the organization has approved or disapproved. As development groups request approval for additional 3rd party libraries and develop successful applications, a list of standards should be created for specific architecture or project types.

For example, an organization may list the following standards for MVC applications in Java and ASP.NET (they typically would expand upon the descriptions as well):

Database Driven Java MVC Application

The organization has standardized on using the following frameworks for Database Driven J2EE MVC applications:

Language: Java 1.6
MVC Framework: Struts 2.x
Dependency Injection Framework: Spring 2.x
ORM Layer: Hibernate 3.x

Database Driven ASP.NET MVC Application

The organization has standardized on using the following frameworks for Database Drive ASP.NET MVC applications:

Language: ASP.NET 3.5
MVC Framework: ASP.NET MVC 1.x
Other: Microsoft AntiXSS Library 2.x

Finally, as the organization matures, a set of secure, shared libraries or frameworks should be created and utilized within software projects. These shared libraries should be scrutinized for security defects and updated on a regular basis. Since assessments and verifications occur on these libraries, teams may not need to spend time and money re-verifying them in their own projects. Instead, only the appropriate usage or coupling of these libraries with custom code must be examined.

Examples of frameworks an organization may produce are:

Secure methods for accessing security services (discussed in the next section)
Secure methods for calling security resources (discussed in the next section)
Input validation frameworks
Unified authentication flows
Authorization or entitlement frameworks
and many more...

Security Services and Resources
A collection of applications often utilize common web services, authentication servers, LDAP servers, or other entities. Organizations should maintain a list of approved security services and resources, guidance informing project teams when it is appropriate to include the services or resources in a project, and the proper method for accessing or calling the service or resource.

Standardization on central services or resources can greatly reduce efforts required to validate applications' security. It also may eliminate the need to create an authentication or authorization strategy for each new project.

Examples of security services organizations may standardize on are:

Authentication/single sign-on servers
Web services providing entitlement or authorization details
Web services that serve as a central point for accessing encrypted credit card data
Web services that provide centralized auditing and logging capabilities
Web services that provide centralized key management and cryptography

Security resources are often centralized data stores that applications can connect to and query. A few examples are:

LDAP servers containing authentication and authorization information
Centralized, redundant file storage and backup

As the organization matures, custom frameworks should be created for accessing or calling functionality in these security services and resources (See the Approved Libraries and Frameworks section above).

Secure Coding Standards
Developers are very good a developing software and implementing business requirements quickly and effectively; however, college, their programming textbook, or their expert programmer friend probably never taught them how to write secure code. In order to ensure developers write secure and consistent code, organizations need to provide secure coding standards to teach and support secure coding practices.

Secure coding standards should be presented in manner that can both teach developers and be used as a quick reference during the development process. It should contain code examples in all approved languages and for each framework. It should also provide examples of what NOT to do. Here is a list of items to consider including within a secure coding standard:

Description of the standard
Statement of why its important
Explanation of when to use the approach or standard
Vulnerabilities that may result if the standard is not observed
Code examples in each language and framework
Code examples of what NOT to do
Links to external resources that provide additional information

A brief example is provided in my previous post "Secure Development Jump Start."

Once these standards are written, they can be matched up with security, compliance, and privacy requirements, which are discussed in the next section. These coding standards allow organizations to hold project teams accountable for writing code that satisfies requirements.

Requirements
A set of common security requirements should be created and shared throughout the organization. These requirements should provide discrete, testable assertions which can be verified throughout the application development process (More on this idea in a later post). An abbreviated example of a security requirement is:

"Applications must use parameterized queries or prepared statements when querying relational databases. Untrusted data must not be concatenated within dynamic SQL query strings."

Another example related to integrating security services guidance is:

"All external facing applications must utilize the organization's standard, centralized authentication server."

The focus of these requirements is to provide a set of rules that developers can be and are held accountable for. Developers often cannot be security experts, but they can be trained to follow and execute on software project requirements. Assuming the organization documents the appropriate guidance and links this guidance to security requirements, development teams can be held accountable for security requirements in the same way they are held to business requirements.

As business requirements are typically implemented based on a prioritized list, it will also be important to allow a member of the organization's security department help prioritize security requirements with project managers.

In addition to security related requirements, privacy and compliance requirements must also be identified. These requirements should be written to satisfy the policies discussed in the "Compliance Policies" and "Privacy Policies" sections above.

Once a reasonable set of security, privacy, and compliance requirements have been established, a set of requirements profiles should be created for various project types. For example, applications that must be PCI compliant will have many compliance requirements that overlap with security and privacy requirements. The requirements profile "High Risk PCI Application" should contain a preprioritized list of requirements that combine and simplify items from the each category.

Vulnerabilities
During the development process, application vulnerabilities are often identified and reported to project teams. Typically, these reports provide a set of recommendations that will eliminate the vulnerability. Depending on the source of these recommendations (a penetration testing tool, code review tool, internal security team, or third party consulting company) the prescriptive advice may or may not coincide with the organization's approved method for eliminating a vulnerability. While general technical flaws like cross-site scripting are fairly straight forward, business logic, authentication, and authorization related issues may require organization specific approaches.

Organizations should maintain a list of vulnerabilities and should link each vulnerability to security, compliance, and privacy requirements that address the issues. This list of vulnerabilities should provide a short explanation of each issue and should label requirements with "Required", "Recommended", and "Optional." The explanation for each issue does not need to be long, many application security sites like OWASP already provide detailed descriptions for many vulnerabilities. Below is an example of how an organization can document vulnerabilities within an internal AppSec Portal:

SQL Injection

SQL injection occurs when untrusted data is interpreted by the database as SQL commands. This issue may allow users to read, modify, or destroy data without authorization.

The following security, privacy, and compliance requirements should be used to address this vulnerability:

Required:

Security: <link to parameterized queries and prepared statements requirement>
Compliance: <link to compliance requirement A>

Recommended:

Security: <link to input validation framework requirement>

Optional:

Security & Compliance: <link to auditing and logging requirement>

Resources:

External Resources
Finally, the organization should provide a set of external resources that project and security teams can use to research application security topics and news.

Internal AppSec Portals: Introduction

2009-06-26T18:40:00.010-05:00

When creating an application security program, it can be difficult to make all the resources, policies, procedures, and expectations available to employees. There should be a centralized location for developers, project managers, and auditors to look up application security best practices, the organization's secure development processes, and time lines for remediating vulnerabilities.

The Software Assurance Maturity Model (SAMM) and Building Security In Maturity Model (BSIMM) recommend addressing these needs using an application security portal (See Software Assurance Maturity Model 1.0, EG3 "Create formal application security support portal" and Building Security In Maturity Model, SR1.2 "Create security portal." This centralized internal website or application should be a one-stop shop for all the organization's secure development needs.

So what kind of characteristics should this portal have? Well, employees should be able to easily create and update information on the website. Access controls need to be applied to specific content to ensure only approved guidance, policies, and procedures are included. The portal should also allow collaboration within development groups as well as between development groups. It would also be nice to be able to version documents to see how and when information changes over time.

After reviewing these characteristics, I realized that a Wiki would provide all these features and could easily be placed within an organization's internal network. Specifically, TikiWiki provides collaboration through user pages, forums, blogs, chat, internal messages, and newsletters. It also allows access controls to be applied to individual categories. For example, a "Guidance" category can be created and pages can be grouped within this category. Read only access can be granted to all users, and write access can be granted to specific individuals responsible for updating the organization's guidance documents. A wiki also automatically versions pages so users can see when information is updated and how it changed. Finally, TikiWiki also provides the concept of structures. Structures group pages in a meaningful way allowing easy navigation and well defined organization of information.

The next several blog entries will cover my current project: providing a template or starting point for organization's internal application security portal. The images below give you a sneak peek at the information that will be discussed in future posts. Click on the images below to see each table of contents.

Repost Web Application Security Portfolios

2009-06-15T08:00:00.004-05:00

In anticipation of my article being published in the May 2009 ISSA Journal, I removed posts for:

Application Security Portfolios: Part 1
Application Security Portfolios: Part 2

Now that the journal article has been out for a while, I wanted to repost those two blog entries. The content in the blog entries is somewhat different than the journal article. The blog entries include a few more images, examples, and additional discussion. Here is that content:

Part 1

Managing an application security program can be a complex responsibility. Applications have a large number of moving parts and potential security risks. Security directors and managers must gather and organize a mountain of information in order to make informed decisions regarding allocating budget money for security and compliance efforts.

This two part blog suggests types of information a security directory might collect about an organization's applications and introduces one of many methods to organize that information. The first article focuses on the collection of detailed information for one single application. The second article attempts to combine relevant information from each application into one single document in order to aide in make decisions.

The goal is for these documents to be useful in at least the following situations:

Maintaining a list of all web applications within the organization.
Prioritizing application security assessment needs based on business and data importance, compliance requirements, and risk.
Identifying key personnel responsible for the security of systems or code associated with a particular application.
Determining network devices, servers, and components to target in an incident response investigation.
Identifying low importance applications that should be assessed due to the shared use of a database or other high importance component.
Understanding the flow of sensitive data between applications and other components.

Part 1: Loan Application Security Portfolio

First, one should gather a list of web applications within the organization. This should be done in a variety of ways including interviewing development managers and web server admins, logging into web servers and inventorying web applications, and by performing network scans over the internal and external network.

Once applications have been identified, basic information should be collected such as the application's name and purpose, who developed the code, where the application is hosted, and business importance. This information can be organized in a variety of ways. A simple excel spreadsheet is shown below for simplicity.

(Click the image to enlarge)

Detailed technical information should also be gathered. This includes items such as the language and framework the application was developed with and the authorization levels that exist. The information shown below is helpful for scoping application assessments with third parties or can be used to estimate time needed for an internal review.

(Click the image to enlarge)

Once the technical information has been documented, security staff can dig into the type of data handled by the application and its data flow. In the example loan application, a table listing the data or event, data type, and relevant compliance requirements was created.

(Click the image to enlarge)

Through interviews with developers and direct observation, a data flow diagram can be created. The method used to collect and present this information was taken directly from Branden R. Williams' article in the ISSA Journal, March 2008 titled "Data Flows Made Easy." In the loans application, individual data flow diagrams were created for key functionality. Once individual diagrams were complete, the diagrams were combined into one compound diagram.

(Click the image to enlarge)

Next, the network devices, servers, and components that the application depends upon should be documented. These assets are also color coded based on how important the application or data is on the asset (this will be more important in part two of the article). Instructions and an example for the loans application is shown below.

(Click the image to enlarge)

Using the dependency table above, pseudo firewall rules can also be defined.

(Click the image to enlarge)

A couple other pieces of information that may be helpful to track are past, present, and future code bases, location of log files, and security related history.

(Click the image to enlarge)

Using the information in the following spreadsheet, one should be able to answer the following questions:

Do we host that application or does a third party host it for us?
Who developed the application?
Does this application need to be assessed?
What additional network devices, systems, or components need to be assessed to assure the security of this application and its data?
Are there compliance requirements associated with this application?
What risk does this application present to the organization?
We've been hacked! Which development manager do I call? Where are the log files? What other systems might also be affected?
Where is the information I can use during scoping and the technical interview process of an assessment from VeriSign Global Security Consulting?

Google Docs Version: http://dl.getdropbox.com/u/1132296/Web%20Application%20Security%20Portfolios/CCANCSA%20-%20Application%20Portfolio.xls

Part 2

Managing an application security program can be a complex responsibility. Applications have a large number of moving parts and potential security risks. Security directors and managers must gather and organize a mountain of information in order to make informed decisions regarding allocating budget money for security and compliance efforts.

This two part blog suggests types of information a security directory might collect about an organization's applications and introduces one of many methods to organize that information. The first article focuses on the collection of detailed information for one single application. The second article attempts to combine relevant information from each application into one single document in order to aide in make decisions.

The goal is for these documents to be useful in at least the following situations:

Maintaining a list of all web applications within the organization.
Prioritizing application security assessment needs based on business and data importance, compliance requirements, and risk.
Identifying key personnel responsible for the security of systems or code associated with a particular application.
Determining network devices, servers, and components to target in an incident response investigation.
Identifying low importance applications that should be assessed due to the shared use of a database or other high importance component.
Understanding the flow of sensitive data between applications and other components.

Part 2: Application Security Portfolios Summary
In part 1 of this series, an application security portfolio was created for an example loan application. Detailed information about the application was gathered including the sensitivity of data within the application, the data flow, and the application's dependencies on other network devices, servers, and components.

In part 2, we will try to organize information about all the organization's applications into one high-level document. The aim is for this document to aid us in answering questions like:

What applications do I have?
What data do I have?
How important is the application or its data to my business?
What risk level is that application or data at?
What Systems and network paths do these applications depend on?
How are these applications and its data interrelated?
Which applications, systems, and networks should I spend security budget money on for assessments?
If an incident occurs or an issue is identified, who is the contact person and what other related systems need to be analyzed?
What compliance regulations apply to my applications?
When was the last time these applications were found to be compliant with relevant regulations and standards?

In order to create this document, the effort described in Part 1 of this series needs to be completed for all the organization's applications. Once that data has been gathered, we can combine the high-level portions into a spreadsheet like the one below.

(Click to enlarge the image)

If we are evaluating this information to determine which applications need assessments, we may make the observations listed below.

Loans Application
The loans application and its data are critical to the business. We completed an application assessment recently on version 1.0, however a whole new version was pushed to production in the last few days (version 2.0). Since this application is so important and we have recently completed an assessment, it may be a good idea to engage the same third party to perform a follow up assessment. We will provide that third part with a list of changes or new features and ensure those items are assessed in depth. In addition, that third party will briefly review the rest of the application to ensure no security issues were introduced in existing functionality by the changes or new features.

If we need a higher level of assurance, need to re-certify our PCI compliance, or drastic changes to the application were made in version 2.0 we may even have a whole new assessment completed.

Company Home Page
An assessment was completed approximate three years ago, and no new changes or features have been introduced since then. While it is important that a public facing website for the company is accessible externally, the data within the application is not terribly valuable.

Depending on the level of assurance needed, we may want to run an automated web application scanner tool just to verify our assumption that the site is relatively secure. If issues are identified, it may be a good idea to perform an assessment internally. Since the company home page does not require users to login and contains only public information, an automated tool is a good choice because the types of vulnerabilities that are challenging to identify using these tools (authentication, authorization, and business logic rules) should not be present.

Online Banking
The online banking application also has not been assessed in a while. This application and its data are critical to the business. The previous assessment occurred on version 3.0. Bug fixes, security updates, and other minor changes were introduced recently in version 3.1. A third party should be engaged to perform follow up testing to verify issues identified in the previous assessment have been addressed. The third party should also assess the minor changes to the application to ensure no additional issues have been introduced.

Internal Wiki
The company's wiki page contains items such as HR policies, processes and procedures for completing day to day tasks, and also contains protected application areas containing private company information or intellectual property. The data associated with this application is critical. This application has never been assessed before. While this application is not a client-facing application, employees, contractors, and other users all access this critical information. This situation may warrant an assessment by a third party.

Employment Application
The employment application is developed and hosted by a third party. Ideally, before this application/service was purchased, a third party assessment should have been performed, and the company should verify that the third party has a secure development process in place. Additionally, the contract between the third party and the company should include details about how assessments are handled, how the third party will respond to the identification of security issues, and other related topics.

As is often the case, a business unit negotiated a contract and purchased service from the third party prior to an assessment being performed. While the employment application does not generate revenue for the company and will not hinder day to day operations if the application goes down, the data within the application includes PII. The compromise of this application and its data will affect the company's reputation and will require the company to spend resources on incident response.

It is a good idea if this application undergoes a third party review.

Compound Dependency Table

In addition to gathering the high-level data above, a dependency table can be created to show how all the applications, data, network devices, servers, and components are interrelated. This table follows the same rules as introduced in Part 1 of this series, and can be used to determine how data flows between systems and networks. Additionally, this information may help to identify key systems that need to be assessed.

For example, if a low importance application accesses data within a database that is also accessed by a high importance application, it may be important to assess the low importance application in terms of introducing or manipulating data to the detriment of the high importance application.

(Click to enlarge the image)

This spreadsheet can be accessed via Google docs here:
http://dl.getdropbox.com/u/1132296/Web%20Application%20Security%20Portfolios/CCANCSA%20-%20Portfolios%20Summary.xls

SAMM Inteview Template Version 1.0

2009-06-07T12:16:00.006-05:00

Several individuals (including me) plan on proposing an effort to evaluate the OWASP organization using the Software Assurance Maturity Model (SAMM). One of the action items I took on was to create an interview template to help determine the organization's current maturity level.

The first release of the SAMM Interview Template is available below.

View the SAMM Interview Template here: http://spreadsheets.google.com/pub?key=rYpVqQR3026Zu4DNg8LBIwg&output=html

Download the SAMM Interview Template XLS here (Some formatting is lost): http://spreadsheets.google.com/pub?key=rYpVqQR3026Zu4DNg8LBIwg&output=xls

If you have questions or comments about this template or you wish to help assess OWASP using SAMM, please send a message out on the OWASP SAMM Mailing List.

Preparing For a Third Party Application Assessment

2009-05-29T12:52:00.006-05:00

Organizations often contract with third party consulting companies to perform application assessments. These companies usually have a predefined window for assessing applications and may charge by the hour. These characteristics make it important for development groups to ensure the application and staff are adequately prepared for the assessment.

For this discussion, we will assume an application assessment has already been scoped and scheduled. Before the consulting company begins any testing, the development group should use a checklist to ensure the following items have been covered:

Appoint a technical contact to handle any questions about code, functionality, or security controls.
Appoint a contact to handle account lockouts or other technical difficulties with the environment or application.
Send contact information to the consulting company or consultants.
Identify and configure a test environment that closely mirrors production.
Create appropriate credentials for a range of organizations and privileged levels.
Populate the environment with adequate data to allow for testing of all functionality and features.
Provide a demonstration of the application and answer technical questions.

Identify and Configure a Test Environment

The test environment should mirror production as closely as possible including the configuration of the operating systems, application servers, back-end components, and the application itself. However, the environment should not persist any transactions or changes in the real world. For example, stock trades, money transfers, etc should appear to complete, but the transaction should not be persisted to any banks.

Create Appropriate Credentials

Each consultant assigned to assess the application needs a range of accounts that allow for testing of horizontal and vertical access controls. This means if the application separates data by organization, company, institution, or some other group, the consultants will need accounts in two or three of these organizational units.

Additionally, within each of these organizational units, consultants require accounts that span several roles, permission, or entitlements. If there are a small set of roles within the application, it may be possible to create test accounts for each role. Otherwise, it may be sufficient to create a sample of accounts, one with no entitlements, one with all entitlements, and a handful of other accounts with varying permission-levels.

Populate the Environment with Adequate Data

In most applications, consultants cannot test functionality without having data associated with their user account. Before consultants begin testing, the application should be populated with test data that allows users to interact with all functionality.

Microsoft SDL Process Template

2009-05-19T12:35:00.005-05:00

Microsoft has released a Visual Studio module that helps developers adhere to Microsoft's SDL process. This tool has a whole lot of things right such as:

Ensuring developers complete security activities before checking in code
Providing a workflow for developers to follow
Providing SDL process steps, instructions, descriptions, and resources to developers

Tools, such a the SDL Process Template released by Microsoft, can greatly increase the success rate of an organization's migration towards a secure software development process. Once organizations define their own custom secure development process, a similar approach should be used to help make adherence easier.

Check out the video on the following page for more information:
http://msdn.microsoft.com/en-us/security/dd670265.aspx

Secure Development Jump Start

2009-05-19T08:00:00.001-05:00

Creating a secure development process for an organization is a huge undertaking. There is a tremendous array of options for getting started and no certain metric for determining how long it should take to adopt the process. Some of those options include:

Software Assurance Maturity Model
Comprehensive, Lightweight Application Security Process
Software Security Touchpoints
Microsoft Secure Development Lifecycle
Building Security In Maturity Model
Create your own custom process

There are some components that all of these processes agree on. Executive level support is a must and security training is required (each process differs on the amount of training, however).

In companies with a small number of developers that have been there for a long period of time, it may make sense to dedicate a large amount of time and money to make them both developers and security experts. For organizations with a large number of developers or high developer turn over rate, it may be more cost efficient to simply provide security awareness training and a set of policies and coding standards to follow.

In any of these situations, several steps you can take to jump start a secure development process for your organization are listed below. It is assumed that your organization values and desires to develop secure code.

Create a policy document addressing application security.
Create a secure coding standard stating the organization's established, secure method for carrying out specific functions.
Provide security awareness training.
Provide training that specifically aims to introduce developers to the application security policies and secure coding standards for the organization.

These steps should fit in to any future secure development process and do not require organizations to spend any security budget dollars on tools. These steps are a starting point and should be joined with a larger, strategic process once the appropriate research and planning is performed.

Application Security Policies

An application security policy document should provide statements or policies that are as specific as possible. A statement such as "All applications should use sufficiently strong cryptographic algorithms" does not provide a developer with enough information to select a secure algorithm. Instead, a statement such as "ACME Bank Corp standardizes on the use of SHA256 as a secure symmetric cryptographic algorithm" should be used.

Other examples include:
"ACME Bank Corp requires all database queries to use parameterized queries or prepared statements. Dynamic or concatenated SQL is prohibited. The ACME Bank Corp secure coding standard provides examples of parameterized queries or prepared statements."

"Untrusted data should be properly output encoded before being included within a web browser page. The appropriate encoding method should be selected based on the context in which the data is being included. The secure coding standard provides example contexts and methods."

The authors of the application security policy document can get policy ideas from resources such as:
OWASP Top 10
2009 CWE/SANS Top 25 Most Dangerous Programming Errors
OWASP Guide Project
ASP.NET 2.0 Check List
ADO.NET 2.0 Check List
.NET 2.0 Check List

Secure Coding Standard

Developers should be able to use the secure coding standard document as a reference guide for writing secure code. The standard should provide the developer with enough information to know when and how to apply a particular code example. An entry such as the following is a good starting point:

Parameterized Queries and Prepared Statements

Addressed Application Security Policy: Parameterized Queries or Stored Procedures, Section 2.1.3
Prevents: SQL Injection
References OWASP Top 10, CWE/SANS Top 25, Security Guidelines: ADO.NET 2.0, OWASP Guide
When to Apply: Anytime an application queries an SQL database
Code Examples:

.NET Parameterized Query, SELECT Statement (example taken from http://msdn.microsoft.com/en-us/library/ms998264.aspx#pagguidelines0002_sqlinjection)

using System.Data;
using System.Data.SqlClient;

using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myDataAdapter = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id",
connection);
myDataAdapter.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myDataAdapter.SelectCommand.Parameters["@au_id"].Value = SSN.Text;
myDataAdapter.Fill(userDataset);
}

.NET Parameterized Query, UPDATE Statement

...

.NET Parameterized Query, INSERT Statement

...

Java Prepared Statement, SELECT

String sql = "SELECT * FROM movies WHERE year_made = ?";
prest = con.prepareStatement(sql);
prest.setInt(1,2002);
ResultSet rs1 = prest.executeQuery();

Java Prepared Statement, UPDATE

...

Security Awareness Training

Security awareness classes are typically used to introduce developers and managers to the types of vulnerabilities found in applications as well as the impact of those issues. When a developer sees for the first time that an SQL injection attack on SQL Server can be used to read arbitrary files and execute DOS commands, a light bulb seems to come on inside their head and they realize they really do need to pay attention and prevent these vulnerabilities.

While these classes often do not arm developers with the proper tools and knowledge for preventing vulnerabilities, a well written application security policy and secure coding standards document should be a great start.

Application Security Policies and Secure Coding Standard Training

Following a security awareness class, it is beneficial to provide a more targeted training opportunity for developers. This course should be focused upon going through the organizations application security policies and coding standards to ensure all developers are aware of these resources and understand how to use and apply them. Following the course, developers can be held accountable for applying the examples in the secure coding standards to their projects.

Process Improvement

It is likely that an application security policy and secure coding standard document will not include all the possible vulnerabilities that could be introduced into a web application. As new issues are identified as part of an assessment, peer review process, or threat model (these steps are usually included within a complete secure development process), additions should be made to both documents. These additions should reflect the organization's recommended approach for developing code without introducing the newly identified flaw. The organization should also periodically review application security concepts and new additions to the policies and standards document with its developers.

ISSA Journal: Web Application Security Portfolios

2009-05-08T10:23:00.005-05:00

My article "Web Application Security Portfolios" was published in the May ISSA Journal!

Check it out here (Must be an ISSA member): http://www.issa.org/Members/Journals-Archive/2009.html#May

Here is another version of the same information.

Struts 2 Security Addons Code Repository

2009-05-07T14:47:00.004-05:00

I have created a code repository for the struts 2 security modules listed in the appendix section of paper "A Gap Analysis of Application Security in Struts2" by Arshan Dabirsiaghi and the OWASP ISWG.

The code repository can be found below, and it allows anyone to download the code and use it within their own project.

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Light-weight Code Review as You Program (Not After You're Done)

2009-05-04T17:55:00.006-05:00

I have been working on a project lately to perform (some) code review as code is written, rather than waiting until it is checked in to cvs/svn/etc. My solution was to create an IDE plug-in that leverages built in features to highlight insecure method calls and suggest alternate code.

When the IDE starts up, it gets an updated list of insecure methods and hints from a web service. Right now I am in the very early stages, so It isn't real pretty or refined yet. For now, I am calling the project Just-in-Time (JIT) Secure Code.

The video below demonstrates the concept in NetBeans.

OWASP ISWG: Struts 2/WebWork Gap Analysis

2009-05-04T11:46:00.006-05:00

Arshan Dabirsiaghi recently published "A Gap Analysis of Application Security in Struts2/WebWork" for the OWASP Intrinsic Security Working Group. The paper evaluates the security controls/features that are either built into Struts 2 or can be added by extending the framework.

I had the opportunity to contribute research and code to this paper. The appendix section contains several code examples showing how one might:

Create an authentication interceptor
Create a roles interceptor (Enforced page-level access controls based on a user's privilege level)
Create a caching headers interceptor
Prevent CSRF vulnerabilities using the built in tokenSession Interceptor
Implement a custom error handler
Create an interceptor that enforces SSL
Regenerate session IDs when users cross an authentication boundary

The paper can be found here:
http://www.owasp.org/index.php/Image:A_Gap_Analysis_of_Application_Security_in_Struts2.pdf

The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

OWASP's SQL Injection Prevention Cheat Sheet

2009-04-17T09:08:00.008-05:00

Recently, SQL injection has become a popular topic in the security world. A quick look at the articles below show that many organizations are suffering from breaches due to SQL Injection. These incidents have lead to the disclosure of credit card numbers, social security numbers, or other personal/sensitive information.

Breach Information:
http://www.webappsec.org/projects/whid/byclass_class_attack_method_value_sql_injection.shtml

http://datalossdb.org/incidents/1230-sql-injection-hack-exposes-names-credit-card-numbers-cvv-codes-of-hundreds

http://datalossdb.org/incidents/1364-sql-injection-hack-exposes-names-addresses-and-ccn

Many development groups struggle to address these vulnerabilities within their software. In March, OWASP released the "SQL Injection Prevention Cheat Sheet." This short article discusses developers' options for addressing SQL Injection. If this article were to become required reading for all developers, I believe it would result in significantly fewer data breach incidents due to web application vulnerabilities.

Software Assurance Maturity Model 1.0 Released

2009-03-26T15:18:00.009-05:00

Pravir Chandra recently released the 1.0 version of the Software Assurance Maturity Model (SAMM). I recommend everyone visits the www.OpenSAMM.org website to review model. Jim Manico also interviewed Pravir on OWASP Podcast #14, where they discussed SAMM becoming an OWASP project and briefly discussed why two distinct models, the Building Security In Maturity Model (BSIMM) and SAMM have emerged.

The newest version of SAMM provides new introductory content including an executive summary and a clear explanation of the model's focus on providing security activities centered around business functions.

Version 1.0 also includes a guide for assessing organizations against the SAMM. Companies can use the provided worksheet consisting of yes or no questions to acertain the maturity of a software security development process. This could be applied to help:

Decide whether to purchase software from a vendor
Determine which software-as-a-service or cloud computing providers to select
Choose whether to develop software in-house or to contract out the work
Determine where the weaknesses in your organization's software security process are
Demonstrate progress in improving your organization's software security process

SAMM also includes roadmaps for various industry types. These roadmaps demonstrate Pravir's assertion that all organizations do not necesarilly need to have a maturity of "3" in ALL security practices. Sample roadmaps are defined for the following industry types:

Independent Software Vendor
Online Service Provider
Financial Services Organization (New)
Government Organization (New)

Again, I encourage everyone to review the Software Assurance Maturity Model at www.OpenSAMM.org.

Cloud Computing Data Security

2009-03-24T08:00:00.005-05:00

Disclaimer: I am not a QSA and am in no way certified to determine whether a network, system, or application is PCI compliant. The information in this article is my opinion only.

A lot of people have voiced concerns about the security and control of data within the cloud. Obviously organizations have significantly more control over data stored within their own infrastructure, but what about data hosted by a third party financial services organization that offers SaaS mobile banking or loan management services versus an implementation within a cloud computing provider's infrastructure? This article analyzes security concerns and the ability to control data in both of the service provider situations. This article will ONLY focus on the data storage aspect of this situation and will ignore things like vulnerabilities in developed applications. In future posts, I may expand the scope.

To set up the context in which these situations will be analyzed, we must first place each provider on equal footing. In this example, both service providers place cardholder data within storage over an encrypted connection (SSL/TLS). In addition, cardholder data is encrypted by the application before being placed within storage. It is assumed that the secret key for the encrypted data is stored on the application server using an appropriate framework such as Microsoft's DPAPI. This means that users with appropriate domain credentials and permissions for the application server may be able to access the secret key.

Threats

I have chosen to analyze data security issues based on potential threats to data within a provider's infrastructure. The following sections dig into each of these threats.

Data Loss or Destruction: Infrastructure Admin Deletes Data

A user with administrative privileges to the data storage infrastructure may maliciously or accidentally destroy the encrypted cardholder data.

Amazon S3 and Third Party Financial Services Provider: Viable Threat

This is a viable threat in both scenarios. A data administrator could delete data in each of these situations.

Data Loss or Destruction: One Data Center is Temporarily or Permanently Unavailable

A natural disaster, power failure, or other situation could render one data center unavailable.

Third Party Financial Services Provider:

My experience indicates that most of these providers utilize multiple data centers located in separate geographic locations within the United States. Depending on whether the additional data center is regarded as a cold, warm, or hot site, data may or may not be immediately available.

Amazon S3:

Data stored within Amazon S3 is stored and immediately available in at least two data centers [1] [2]. If one data center becomes unavailable, data will still be accessible to applications in the other data center.

All US Data Centers are Temporarily or Permanently Unavailable

If some kind of significant event affects the US's Internet infrastructure, multiple data centers could become unavailable.

Third Party Financial Services Provider:

Third party providers may or may not have data centers in locations outside of the US.

Amazon S3:

Data in Amazon S3 is not automatically backed up to data centers outside of the US; however as a mitigating control, organizations can choose to periodically backup data to Amazon S3 buckets within the UK [5].

Data Loss or Destruction: "Hacker" Destroys Data

A hacker could exploit a vulnerability within a system or network device that allows access to or control of data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to delete, destroy, or render that data inaccessible.

Third Party Financial Services Provider:

Customers rely on the third party providers to place appropriate access controls around data and to apply security patches to network and system devices in a timely manner.

Amazon S3:

Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.

Unauthorized Data Access: Infrastructure Admin Accesses Data

A user with administrative privileges to the data storage infrastructure may attempt to access cardholder data for the purpose of financial gain.

Third Party Financial Services Provider:

Since the third party provider maintains the secret key for the encrypted data, it may be possible that an unauthorized individual may have domain privileges to access the secret key and the encrypted cardholder data. This would directly result in a compromise of customers' credit cards.

Amazon S3:

An administrator for Amazon S3 may be able to access the cipher-text for cardholder data; however the administrator would not have access to the secret key used to encrypt the data. It would be very difficult for that administrator to discover or brute force the secret key associated with that data.

Unauthorized Data Access: "Hacker" Accesses Data

A hacker could exploit a vulnerability within a system or network device that allows access to data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to read or steal that data for financial gain.

Third Party Financial Services Provider:

Customers rely on the third party providers to place appropriate controls around data, to apply security patches in a timely manner, and to encrypt data at rest and while in transit.

Amazon S3:

Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Data can be encrypted prior to being placed within cloud storage, rendering stolen data useless for an attacker. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.

Unauthorized Data Modification: Infrastructure Admin Modifies Data

A user with administrative privileges to the data storage infrastructure may attempt to modify cardholder data for the purpose of financial gain.

Third Party Financial Services Provider:

Since the third party provider maintains the secret key for the encrypted data, it may be possible that an unauthorized individual may have domain privileges to access the secret key and the encrypted cardholder data. This would allow an attacker to modify cardholder data or other assets within the data store.

Amazon S3:

An administrator for Amazon S3 may be able to access and modify the cipher-text for cardholder data, however the administrator would not have access to the secret key used to encrypt the data. It would be very difficult for that administrator to discover or brute force the secret key associated with that data.

Unauthorized Data Modification: "Hacker" Modifies Data

A hacker could exploit a vulnerability within a system or network device that allows access to data (remember, we are intentionally ignoring application level issues in this particular article). The attacker may choose to modify that data for financial gain.

Third Party Financial Services Provider:

Customers rely on the third party providers to place appropriate controls around data, to apply security patches in a timely manner, and to encrypt data at rest and while in transit.

Amazon S3:

Customers can place bucket or object-level access controls around data within Amazon S3. Customers directly control the application of security patches to virtual images. Data can be encrypted prior to being placed within cloud storage. Customers rely upon Amazon to apply patches to flaws identified within S3 or Amazon's API.

Miscellaneous: Data Stored in Hostile Country

It is important for customers to ensure sensitive data or intellectual property is properly protected. Some countries do not have adequate laws or security standards in place to protect sensitive data or to restrict seizure of data by the government.

Third Party Financial Services Provider:

Third party providers typically are aware of these concerns and likely will not host data within a hostile country.

Amazon S3:

Customers of Amazon's S3 service may choose the country in which data is stored. Customers can choose to create a bucket in the US or in the UK [5].

Miscellaneous: Availability Issues

When data or services are unavailable, companies may lose revenue during the down time and may loose customers concerned with reliability of data or applications.

Third Party Financial Services Provider:

Availability and SLAs vary for each third party financial services providers.

Amazon S3:

The S3 storage system is highly available and stores data redundantly in multiple geographic locations. Amazon provides a SLA of 99.9% up time per month [4]; however they have had an issue or two in the past with availability [3].

Conclusions

To summarize the findings above, I created a table listing threats, mitigating factors, and risk levels.

(Click the image to enlarge)

One major concern voiced regarding cloud computing is the control of data. Organizations do not want sensitive data accessed by service providers or disclosed/stolen due to security issues related to the provider's infrastructure. Surprisingly, the findings above show customers have a greater level of control over data stored within Amazon's S3 cloud storage service as compared to utilizing a third party financial services provider.

When analyzing threats to data security, findings show customers have the potential to implement stronger security controls around sensitive data stored in the cloud as compared to third party service providers. These finding my be misleading; however as many financial service providers invest heavily into developing strong information security programs, typically have a range of security experts in house, and engage in independent assessments to verify the security of networks, systems, and applications.

After considering all the data, I think the most important point to take away from this is actually not whether one solution is more secure than the other, but instead that data can be stored within the cloud in a secure and robust manner. Organizations should evaluate the choice to adopt cloud storage on the basis of whether it improves the business or generates additional revenue and should not make the decision based on fear of customer data being compromised or stolen.

References

http://s3.amazonaws.com/aws_blog/AWS_Security_Whitepaper_2008_09.pdf

"Data stored in Amazon S3, Amazon SimpleDB, or Amazon Elastic Block Store is redundantly stored in multiple physical locations as a normal part of those services and at no additional charge."
http://developer.amazonwebservices.com/connect/thread.jspa?threadID=11831&start=15&tstart=0

"I guess in my last message I neglected to clearly reiterate what we've said before, which is consistent with what Jeff said in his talk - we store multiple copies in multiple data centers. Yes, that means at least two. We don't ack a PUT until those multiple copies in multiple datacenters have been stored. The only exception to this is if a datacenter receiving your PUT is totally isolated from other datacenters due to a network issue. In that case, the multiple copies are stored in the single active datacenter, and then one or more of the copies are migrated to separate datacenters when connectivity is attained. This is a very rare occurance though."
http://status.aws.amazon.com/s3-20080720.html
http://aws.amazon.com/s3-sla/
http://aws.amazon.com/s3/

"A bucket can be located in the United States or in Europe. All objects within the bucket will be stored in the bucket’s location, but the objects can be accessed from anywhere."

Mosso - First PCI Compliant Customer Through Self Evaluation and Scanning

2009-03-05T09:06:00.009-06:00

Mosso, a PaaS cloud provider, claims to be the first in enabling a customer to be PCI compliant within the cloud. Naturally, this really excited me as I have spent a lot of time lately trying to figure out how to acomplish PCI compliance in the cloud. I was somewhat disapointed, however, once I read the details.

In this case, the application within the cloud does not actually store any credit card data. The customer leverages a third party payment gateway to handle collection and storage of all cardholder data.

Additionally, the customer did not gain PCI certification through an evaulation by a Qualified Security Assessor (QSA), but instead only needed to complete a "Self Assessment Questionaire" and pass a scan from an approved scanning vendor (ASV).

Since the application used a third party payment gateway to handle collection and storage of cardholder data, only a subset of the PCI DSS controls applied to this application. According to Mosso's article, only requirement 9 (Restrict physical access to cardholder data) and 12 (Maintain a policy that addresses information security) applied.

It's wonderful that some level of PCI compliance has been achieved for applications within the cloud, but I feel like this isn't much different than Amazon EC2 + Amazon Flexible Payments Service, or even simpler any cloud provider + Paypal. Hopefully in the future, we will have a case study in which an application that handles cardholder data will become PCI certified within a cloud computing provider's infrastructure.

Resources:

http://blog.mosso.com/2009/03/cloud-hosting-is-secure-for-take-off-mosso-enables-the-spreadsheet-store-an-online-merchant-to-become-pci-compliant/

http://www.mosso.com/docs/PCI_HowTo.pdf

http://aws.amazon.com/fps/

PCI Compliance and Cloud Computing

2009-02-26T09:20:00.029-06:00

Disclaimer: I am not a QSA and am in no way certified to determine whether a network, system, or application is PCI compliant. The information in this article is my opinion only and is intended create an open discussion about how companies subject to PCI can leverage cloud computing in their overall business strategy. If you disagree with any of my observations or conclusions, please add a comment and explain your argument, it's very likely that you are right ;-)

References:
PCI DSS version 1.2
Amazon's AWS Security Whitepaper

As I began researching cloud computing, one question I continually asked others is how payment card applications or data could be placed in a cloud computing provider's infrastructure in a PCI-compliant manner. So far, I have not received a definitive answer to this question.

In order to understand the implications of this question, I decided to read through the PCI standard and try to determine what controls would need to be in place for an example company and implementation. In this example, a fictitious financial services company wishes to leverage Amazon's EC2, EBS and S3 offerings to host a loan payoff application and its data. This application allows customers to view current loan information and pay balances using a credit or debit card.

The network and server architecture for this system will be identical to the "Basic Failover Architecture" presented in RightScale's wiki. The application will be written in Java and the database will be SQL Server 2005. Database backups will be encrypted and archived using Amazon's S3 cloud storage. Communication between the client and the web server, the web server and the database server, the master database server and the slave database server, and the database servers and Amazon's S3 service will be encrypted using SSL.

PCI DSS Scope

The PCI DSS document, page 5, states network segmentation of credit card data or activities may limit the scope of a PCI assessment. The PCI assessor must evaluate the effectiveness of network segmentation controls and then make a decision based on these results.

In a cloud computing environment, there are both physical and virtual infrastructure devices that provide segmentation. Amazon's Security Whitepaper discusses the following components that provide segmentation:

Configurable firewall (implemented at the Hypervisor layer)
Strong separation of guest OS and Hypervisor
Instance isolation (separation of running virtual images)
Prevention of packet sniffing by other tenants
Configurable "security groups" (similar to VLANs)

Based on these items, organizations should be able to limit the scope of assessments to "security groups" that contain payment applications or data. It is unclear whether the scope must include Amazon's physical network devices or web services associated with managing or manipulating Amazon's EC2 or S3 services. There is software segmentation between items like the host OS and the guest OS as well as between multiple guest OS's; however since payment data travels through all these systems, there may not be sufficient data segmentation to exclude the above Amazon components.

Takeaway: "segmentation" needs to be evaluated as it applies to virtual infrastructure and Amazon's physical infrastructure.

PCI DSS and Third Party Service Providers

Page 6 of the PCI standard discusses situations in which a company uses a third party service provider to provide cardholder data services. This section states that an assessor must clearly state which third party components should be included within a PCI assessment. The third party must have a PCI assessment conducted; however this assessment can be conducted at the time of the assessment of the original company. This means that cooperation from cloud computing service providers may be required to gain PCI-compliance for components within the cloud.

Takeaway: Companies will need to establish compliance of at least some of the cloud provider's components AND companies will likely need cooperation from cloud providers in obtaining PCI compliance.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

There are a number of items within this requirement that refer to creating network diagrams, implementing firewalls, and other similar network controls. Organizations can easily fulfill these requirement as they apply to the virtual infrastructure within the cloud using the provided "security groups", Hypervisor firewall, and other similar features.

The unanswered question is to what extent the requirement applies to Amazon's physical infrastructure. This is particularly a problem if servers are constantly being spun up or down to automatically adjust based on needs/requirements. In addition, Amazon's S3 storage mirrors data across a number of geographically diverse locations. Documenting and assessing Amazon's the physical network for PCI is very tough. On the other hand, it may be sufficient to assess a sample of Amazon's data centers or physical network devices where data or servers could potentially be located.

Takeaway: It is unclear to what degree the cloud provider's physical architecture will need to be assessed in addition to the organization's virtual infrastructure.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

This section concerns default passwords, disabling unnecessary services, secure configuration of components, and the use of SSL. Most of this information applies to the virtual infrastructure.

However, item 2.4 and Appendix A list requirements that apply to shared hosting providers. These rules are concerned with segmentation of cardholder data, logging and forensics. Based on the controls implemented by the Hypervisor as well as authentication and authorization controls in place for accessing cloud storage, it is likely segmentation controls are satisfied. Logging and forensics concerns may require the creation of virtual images suited for these purposes or may require cooperation from the cloud computing provider.

Takeaway: Companies may need to plan ahead and/or get cooperation from cloud providers regarding logging and forensics. Specialized virtual images can be created to assist with forensics or incident investigation.

Requirement 3: Protect stored cardholder data and Requirement 4: Encrypt transmission of cardholder data across open, public networks

Secure storage and transportation of cardholder data is an important aspect of the PCI standard. Controls outlined in the document can be easily accomplished by the company implementing the virtual infrastructure. These companies are fully capable of encrypting data before storing it within EBS or S3, utilizing full disk encryption within virtual images, and leveraging SSL to securely send sensitive data between components.

Takeaway: This requirement can be satisfied without the cooperation of the cloud computing provider.

Requirement 5: Use and regularly update anti-virus software or programs

Anti-virus can easily be applied to virtual images. It may also be necessary for companies verify and document the cloud provider's use of anti-virus as it applies to Host OS's, cloud storage, and other related components.

Takeaway: Companies should verify and document the cloud provider's use of anti-virus on Host OS's, cloud storage, and other components.

Requirement 6: Develop and maintain secure systems and applications

I am going to separate this section into two parts. One part is concerned with the secure development of custom applications. While it is straight forward to understand how this applies to the company implementing the virtual infrastructure, its not as clear whether items like Amazon's web services need to be pen-tested or verified. Hopefully, Amazon has already completed an assessment on these components and organizations can simply receive a high-level overview of the result.

The second part is concerned with applying security updates in a timely manner. This requirement can likely be satisfied by verifying and documenting Amazon's patch management procedures.

Takeaway: It's unclear whether the cloud computing provider's applications (like Amazon's web services) must be assessed. Additionally, the cloud provider's patch management process should be verified and documented.

Requirement 7: Restrict access to cardholder data by business need to know

Amazon has stated that they do not have shell or other similar access methods to organization's running virtual images. So far, I am unable to find any literature from Amazon that explicitly states that the provider cannot read or modify companies' data with S3 or EBS. This concern should be addressed with the provider prior to a PCI assessment. It's likely that even if this data is encrypted and Amazon can only access the cipher-text containing cardholder data, this will still not satisfy requirement 7.

Takeaway: Organizations should verify Amazon administrators cannot access or modify data (encrypted or unencrypted) within EBS or S3 storage.

Requirement 8: Assign a unique ID to each person with computer access.

While this section applies to standard items such as remote access user accounts and web application user accounts, it also applies to the management and manipulation of virtual images within Amazon EC2. Currently, Amazon does not include the ability to create multiple user accounts to be assigned to various system or network administrators within an organization. This means everyone must share a single account to turn on images, remove images, and make firewall changes.

One way this can be addressed is by creating a custom interface to Amazon's API. The custom interface should require users to login with unique user accounts. Services such as RightScale provide this functionality as well.

Takeaway: Roll your own interface to Amazon's API or leverage third party services like RightScale for requiring unique accounts and assigning privileges to administrators of the company's virtual infrastructure.

Requirement 9: Restrict physical access to cardholder data.

Data centers containing cardholder data should have controls in place to ensure only authorized individuals can gain physical access to network devices and systems. In order to be compliant, companies may need to verify and document how the cloud provider satisfies physical security concerns for requirement 9.

Takeaway: Organizations will need the cloud provider's cooperation to verify physical security requirements in the PCI standard are satisfied.

Requirement 10: Track and monitor all access to network resources and cardholder data.

Tracking and monitoring data access, creation of logs, and retention of logs are all items that a company can control within the cloud without the service provider's help. This section also requires internal/external network and application vulnerability scanning and penetration testing. Organizations can create vulnerability scanning engines and remote penetration testing boxes to satisfy these requirements, however the cloud server provider should be notified before performing any of these tests.

Implementation of a network intrusion detection/prevention system within the cloud may be difficult for organizations, but it may be sufficient to implement host intrusion detection software on each virtual image.

Takeaway: Create virtual images to complete tasks such as vulnerability scanning and penetration testing. Investigate the ability to implement a network intrusion detection system. If this is not possible evaluate whether host intrusion detection software is an appropriate mitigating control.

Requirement 12: Maintain a policy that addresses information security for employees and contractors.

Organizations will need to create security policies and procedures around management of resources within the cloud provider's infrastructure. Since cloud computing is somewhat new, this may be easier said than done.

Takeaway: In addition to existing information security policies, documentation need to be written regarding appropriate use and management of resources within the organization's virtual infrastructure.

Create a Security Strategy Before Utilizing Cloud Computing

2009-02-19T09:39:00.008-06:00

Cloud computing providers such as Amazon EC2/S3, Microsoft Azure, or Google AppEngine offer pay-as-you-go services for hosting data, applications, servers, or entire data centers using the provider’s infrastructure. Cloud computing enables customers to scale resources up or down based on demand. This allows large retail web sites like Target.com handle an exponential growth in web traffic during “Black Friday” sales without wasting money on additional hardware that will only be used a few times a year.

Cloud computing resources are said to be elastic in that the customer can instantiate 5,000 machines within the cloud and only use (and pay for) the resources for two hours. HIPAA-compliant companies like TC3 Health use this strategy for processing months or years worth of healthcare claims in a short period of time.

Cloud storage can be leveraged to store large amounts of data in a highly available, globally accessible, fault tolerant manner. These benefits lead Nasdaq to add 30 to 80 gigabytes of data to Amazon’s S3 storage daily.

Cloud service providers like Amazon are partnering with big technology players like IBM, Oracle, Sun, and RedHat to appeal to enterprise clients. Experts predict that as offerings and underlying technologies mature, Fortune 500 companies will soon incorporate cloud computing into their business and IT strategy.

Companies who wish to adopt cloud computing should identify how their risk profile will change after moving from a traditional data center to a virtual one. Examples of security and compliance risks companies should address before adopting cloud computing are listed below. There are a large number of business risks to consider as well. The list below does not include any business risks.

Compliance – When processing or storing credit card, banking, healthcare, or personally identifiable information within the cloud, organizations should create a strategy for ensuring the virtual implementation and the service provider will be compliant with relevant regulatory requirements or security standards.
Application Layer Security – Organizations should assess whether new vulnerabilities related to accessing cloud storage, cloud databases (Amazon’s simpleDB, Google’s BigTable, or Microsoft’s SQL Data Services), or other technologies have been introduced into application code.
Operational Security – A documented set of policies should be created regarding the use and management of cloud computing resources. For example, most cloud computing providers utilize a single set of credentials for making changes to the virtual data center. Organizations should not provide these credentials to every data center administrator nor should changes be made without proper approval. In addition, organizations should discuss the service provider’s operation security policies to ensure an appropriate level of assurance is provided.
Incident Response – Organizations should identify a strategy for performing incident response within the cloud. This may require cooperation from the cloud computing service provider, or a custom incident response machine image for services like Amazon EC2 or GoGrid.

Below is a list of companies leveraging cloud computing today:
Animoto
Target.com
TC3 Health
Nasdaq

Here are several popular cloud computing providers:
Amazon AWS
Microsoft Azure
Google AppEngine
SalesForce.com
Mosso Cloud Sites/Files
GoGrid

Cloud computing security papers:
Above the Clouds: A Berkeley View of Cloud Computing

OWASP's XSS Prevention Cheat Sheet

2009-01-23T08:49:00.004-06:00

The Open Web Application Security Project (OWASP) has recently released a XSS (Cross Site Scripting) Prevention Cheat Sheet. This cheat sheet helps developers identify how and when to output encode or escape untrusted user data when including it within a page. I am particularly excited about this resource because it not only discusses the case in which HTML encoding is necessary, but also helps layout rules or conditions for using JavaScript, CSS, Attribute, and other encoding schemes.

It is important for developers to understand that the appropriate encoding scheme must be applied based on the context in which untrusted user data is being included within the page.

As a side note, RSnake's XSS cheat sheet, used by security staff to identify cross-site scripting attacks, has been around for a while. These two cheat sheets seem to compliment each other well.

Page-Level Access Controls in Struts 2 - Part 2

2008-12-19T10:00:00.002-06:00

Background

Applications should ensure users are properly authenticated and have sufficient permissions to access pages before content is displayed. Page-level access controls are one security control that enforces this behavior.

Part 1 and 2 of this article describes one of many ways to implement a Struts 2 AuthenticationInterceptor and a RolesInterceptor to verify users have authenticated successfully and belong to an approved role before allowing access to pages. The key features targeted by both interceptors include a default deny policy and a centralized location for defining access control rules.

Struts 2 RolesInterceptor

In Part 2 of the page-level access controls article, a RolesInterceptor has been added to the struts.xml file. The "roleActions" parameter, passed to the interceptor, contains a list of actions allowed for each role. The "*" role indicates that any role can access the action.

Struts.xml

(Click the image above to view the XML)

Similar to the AuthenticationInterceptor, the RolesInterceptor verifies all users are allowed access to a particular page or validates that the user's "role" session variable matches one of the roles allowed for the action requested.

RolesInterceptor

(Click the image above to view the code)

In the ProcessSimpleLogin action, the "role" session variable has been added to include the name of the role that the user belongs to.

ProcessSimpleLogin

(Click the image above to view the code)

The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Page-Level Access Controls in Struts 2 - Part 1

2008-11-20T12:51:00.002-06:00

Background

Struts 2 AuthenticationInterceptor

In the struts.xml file below, the AuthenticationInterceptor is defined and included in the defaultSecurityStackWithAuthentication. The "excludeActions" parameter provided to the interceptor lists the actions that do not require users to be authenticated. In this case, the "Login" and "ProcessSimpleLogin" actions do not require authentication, however the "Internal" page does require authentication.

Struts.xml

(Click the image above to view the XML)

When the AuthenticationInterceptor is called, the interceptor verifies the requested action is in the exclude list or the user has the "authenticated" session variable set to "True."

AuthenticationInterceptor

(Click the image above to view the code)

Finally, to allow users access to authenticated pages, the ProcessSimpleLogin action verifies the submitted credentials and then sets the "authenticated" session variable to "True."

ProcessSimpleLogin

(Click the image above to view the code)

CSRF Prevention in Struts 2

2008-11-10T09:23:00.003-06:00

Background

Cross-site request forgery, one of the OWASP Top 10 vulnerabilities for 2007, is an attack in which a malicious user causes a victim's browser to make a request without the user's consent. This attack is generally propagated by a third party site.

The example below shows how a CSRF attack might affect a web application that allows customers to request rental movies to be mailed to their house.

A customer logs into her movie rental web site and selects some movies to add to her queue. Next, instead of logging out of the application, she types in the address for her favorite news site, reads a few online comics, and does some research on used cars.

Unfortunately, before the customer began her research, an attacker had discovered a persistent cross-site scripting vulnerability on one of the used car sites. The attacker had also exploited this vulnerability to include a simple image tag containing a URL similar to the one below:

<img src="http://www.fakemovierentalsite.com/addMovieToQueueBeginning?movieId=12345" />

When this image tag loaded in the customer's browser, a request was sent to the movie rental application to add an embarrassing movie to the beginning of the customer's queue.

One strategy to address CSRF attacks is to require and validate one-time values included in requests to sensitive functionality. For more information, please view the OWASP explanation found here.

Struts 2 tokenSessionInterceptor

The tokenSessionInterceptor, provided by struts 2, allows developers to add CSRF protection quite easily. In the example below, the tokenSessionInterceptor was added to the interceptor stack. A parameter has been passed to the interceptor to ensure it will not be triggered on each request.

In the ProcessSimpleLogin action, the tokenSessionInterceptor is referenced again. In this case, a parameter is passed to the interceptor to ensure it verifies a valid token has been sent for this action only.

(Click the image above to view the XML)

In order to include the proper token within the page, the <s:token /> tag is included as shown below.

(Click the image above to view the code)

This strategy ensures the ProcessSimpleLogin action executes only if a one-time token has been associated with the user's session, the request includes this token, and the token has been used only one time.

The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Custom Error Pages in Struts 2

2008-11-02T16:33:00.003-06:00

Background

When attackers target a particular application, they typically spend some time gathering information about the application's components, framework, and architecture. One way attackers may gather this type of information is through error messages.

Error messages often disclose SQL queries, code fragments, file names, or other sensitive information. An example is shown below.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 xx.xx.xx.xx 10/18/08 17:49:20 clientid=&id= http://www.google.com/search?q=

[Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax near '='.

SQL = "SELECT * FROM logins WHERE clientid ="

Data Source = "AFE2003"

The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (40:2) to (40:47) in the template file E:\inetpub\i\somesite\showinv\Application.cfm.

The disclosure of this information can be avoided using custom error pages. Applications, frameworks, or servers can be configured to redirect users to a custom error page that does not disclose stack traces, debugging information, or verbose error messages.

Struts 2 Custom Error Pages

Struts 2 includes an Exception Interceptor in its default stack. Developers can utilize this interceptor to catch errors and redirect users to a page containing a generic error message. One example is shown below.

Custom Error Page

(Click the image above to view the code)

Struts.xml

(Click the image above to see the XML)

Result

SSL/TLS in Struts 2

2008-10-19T18:41:00.010-05:00

Background

SSL/TLS provides an encrypted communication channel that a client and server can use to exchange messages without an attacker eavesdropping or manipulating data in transit. This is an important security control to include within a web application to ensure attackers cannot steal user's authentication session cookies or observe user's credentials as they are transmitted to the server.

Web applications and their environments should ensure users can only access sensitive applications over an encrypted communication channel (https for example). Firewalls, application servers, or applications themselves can enforce this behavior.

Requiring SSL/TLS in Struts 2

One way to ensure users connect using SSL or TLS within struts is to create an interceptor to verify this connection. An example has been provided below.

SSLRequired.jsp

(Click the image to view the code)

RequireSSLInterceptor

(Click the image to view the code)

Struts.xml

(Click the image to view the XML)

HTTP Caching Headers in Struts 2

2008-10-18T12:59:00.026-05:00

Background

In many cases, the users' web browsing experience can be made more efficient by allowing web browsers to cache pages, images, scripts, and other content. This allows the web browser to retrieve content from the local disk rather than requesting data from the server every time. The end result is a quicker, more responsive user interface.

While this strategy is great for applications that handle public, non-sensitive information, it may not be appropriate for banking, investment, health care, or other similar applications. In general, applications that contain sensitive or confidential information should have controls that reduce the likelihood of information being disclosed to unauthorized individuals.

One way web applications can reduce the likelihood of browsers disclosing sensitive data through caching is to include the following HTTP headers within the server's response.

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

For more information, please see the OWASP AppSec FAQ.

Struts Interceptor Implementation

One way these headers can be included within a Struts 2 application is to create a custom interceptor. An example has been provided below.

CachingHeadersInterceptor Code

(Click the image above to view the code)

Struts.xml

(Click the image above to view the XML)

Results

Server: Apache-Coyote/1.1
Cache-Control: no-cache, no-store
Pragma: no-cache
Expires: -1
Content-Type: text/html
Content-Length: 157
Date: Sat, 18 Oct 2008 18:37:35 GMT

200 OK

JSESSIONID Regeneration in Struts 2

2008-09-04T12:16:00.024-05:00

Background

Whenever a user crosses an authentication boundary, the user's session ID should be regenerated. This concept applies to a user logging into an application, logging out, or when a user reauthenticates due to a risk-based authentication process. The regeneration of session IDs is an important practice that helps eliminate session fixation vulnerabilities and may limit the impact of session theft vulnerabilities prior to authentication.

For more information on Session Fixation vulnerabilities and Session ID regeneration practices, please see the OWASP pages below:

http://www.owasp.org/index.php/Session_Fixation
http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens

Session ID Regeneration in Traditional Java Web Applications

In a J2EE application, the user's JSESSIONID cookie should be regenerated and the previous session should be removed or deleted from the server. Example code below shows how this might be accomplished in a traditional Java web application.

public class ExampleLoginServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
if( //authentication was successful ) {
request.getSession().invalidate();
HttpSession session = request.getSession(true);
session.setAttribute("AUTHENTICATED", new Boolean(true));
response.sendRedirect("PageRequiringAuthentication.jsp");
//Additional Code Would Normally Follow

Session ID Regeneration in Struts 2 Applications

In Struts 2 applications, developers typically don't directly interact with the HttpServletRequest, HTTPServletResponse, or HttpSession objects. With consideration of these factors, the solution discussed above for a traditional Java web application may not be appropriate for Struts 2.

I did a little research and through trial an error I came up with a Struts 2 specific solution for regenerating JSESSIONIDs. This solution utilizes the SessionAware interface. Please excuse the unrealistic authentication code...

package nickcoblentzblog.actions.sessions;

import java.util.Map;
import org.apache.struts2.interceptor.SessionAware;
import com.opensymphony.xwork2.ActionContext;
import com.opensymphony.xwork2.ActionSupport;
import org.apache.struts2.dispatcher.SessionMap;

public class Login extends ActionSupport implements SessionAware  {
private String userid;
private String password;
private Map session;

public String execute() {
if(userid.equals("admin") && password.equals("admin"))  {

/* Session ID Regeneration: Try #4 */
((SessionMap)this.session).invalidate();
this.session = ActionContext.getContext().getSession();
/* End Try #4 */

session.put("AUTHENTICATED", new Boolean(true));


return SUCCESS;
}
else
return ERROR;
}
public String getUserid() {
return userid;
}
public void setUserid(String userid) {
this.userid = userid;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}

public void setSession(Map session) {
this.session = session;
}
}

To test this code, I followed the following procedure.

1. Cleared all browser cookies
2. Visited the Login JSP page
3. Used the Web Developer Toolbar to view my initial JSESSIONID
4. Logged into the application successfully
5. Used the Web Developer Toolbar to view my final JSESSIONID

The initial JSESSIONID value was:
AA4996C5E24BB8221BB27B23EA599F34

The final JSESSIONID value was:
325ED18851B93EBA542D2AE7926E7F8E

Based on these tests this solution appears to work successfully.

In case anyone is curious, here are a couple other ideas I toyed with:

/* Try # 1:
this.request.getSession().invalidate();
this.request.getSession(true);
*/

/* Try #2:
HTTPUtilities esapiHTTPUtilities = ESAPI.httpUtilities();
esapiHTTPUtilities.setCurrentHTTP(request, response);
try {
esapiHTTPUtilities.changeSessionIdentifier();
}
catch(Exception e) {
e.printStackTrace();
}
*/

/* Try #3:
((SessionMap)ActionContext.getContext().getSession()).invalidate();
*/

Ubiquity Security Concerns Part 1: An Introduction

2008-08-30T12:36:00.023-05:00

Introduction

I recently watched a short video about a Mozilla Labs project called Ubiquity. After watching this video, I became extremely excited about using the features presented and extremely scared of how the extension could be exploited to compromise personal data. I wanted to both benefit from this awesome and fun extension and also find ways to execute arbitrary JavaScript within others' browsers (the same feeling I get whenever I use Google). It may be helpful to briefly watch this video to understand this sentiment:

http://www.vimeo.com/1561578?pg=embed&sec=1561578

After watching this video, my first thoughts were:

1. I wonder if an attacker could write a command to send arbitrary GMail messages on the users' behalf, watch every page the users visit, steal passwords, and even compromise users' computers.

and

2. How difficult would it be for an attacker to trick a user into installing the command or cause the command to be installed in an automated fashion?

The short answer to 1. is YES (details provided below)! Answering 2., specifically the automated portion, will require some research.

Ubiquity Developers' Awareness of Security Concerns

Before anyone gets too worked up about these security issues, I should make sure it is clear that this project is far from being complete, the authors are well aware that there a significant security concerns, and they are in the process of determining a method to reduce the risk of malicious commands or other exploits.

Examples of this awareness can be found in Atul's blog entries:

Trusting Functionality and Towards Inter-Community Trust

"At present, because our project is still in the prototyping stage, we’re opting for freedom of expressiveness and experimentation over security. That means that all the various verbs we write, while written in JavaScript, are always executed with Chrome privileges, meaning that they’re capable of doing whatever they want to the end-user’s computer."

"So the particular dilemma that needs to be solved here is: how can an end-user trust that a verb won’t do anything harmful to their data or privacy—be it intentional or accidental—while still providing a low barrier of entry for aspiring authors to write and distribute their own verbs?"

More specific concerns can be found in the Ubiquity Author Tutorial.

Ubiquity_0.1_Author_Tutorial#Sharing_it_with_the_World

"If the user chooses to subscribe to a command from an untrusted source, they will get a security warning message before they can install the command. (And in Ubiquity 0.1, ALL sources are considered untrusted, so don't take it personally!) Because Ubiquity commands can execute arbitrary javascript with chrome privileges, subscribing to a command from a website means allowing that site full access to do whatever it wants to your browser. We want to make sure people understand the dangers before subscribing to commands, so we made the warning page pretty scary."

"In the future, we're going to have something set up that we call a "trust network". When you try out a Ubiquity command from a website, and determine that the command is safe (or unsafe), you'll be able to leave an approval (or a warning). When your friends with Ubiquity installed visit the same site, they'll see the approval or the warning that you left. In this way, users will be able to rely on the judgement of other people they already know and trust in order to help them make decisions about whether a command is safe to install or not."

"By the way, the reason we call it "subscribing" to a command, rather than "installing" a command, is that if the javascript file changes -- if the site owner adds new commands, removes old commands, or updates existing commands -- all users subscribed to that URL will automatically get the updates. This will be very convenient for both users and developers, but it will also introduce another type of security risk: just because you decided a command was safe at one point in time doesn't mean that the command will always remain safe. For this reason, we'll need to make sure that the trust network keeps track of when commands have been modified, and notifies users of changes that may make a command unsafe."

Possible topics for Part 2 - ?

I plan on digging into these ideas in future posts, and have listed a few possibilities below. If you have a preference or other suggestions, feel free to leave a comment.

Using Ubiquity for Evil:
Basically, a discussion of Ubiquity features and how they could be used maliciously.

Subscription Exploits:
Results of research into whether commands could be installed in an automated fashion without the user's permission.

Ubiquity Trust Model:
Examination of how the trust model protects users from subscribing to malicious commands. This article may have to occur once that trust model has been determined by the project developers.

Presentation Layer Output Encoding: Apache Commons Lang StringEscapeUtils vs. OWASP Reform

2008-08-09T11:17:00.094-05:00

*Updated to include OWASP ESAPI Results on August 21, 2008*

In order to compare the effectiveness of the Apache Commons Lang StringEscapeUtils and the OWASP Reform library, I created a JSP page that encodes ASCII values from 0 to 255. I chose to examine the ability of each library to encode HTML and JavaScript values for the purpose of preventing cross-site scripting attacks. The results are shown at the bottom of this post.

In general, both the ESAPI and Reform libraries encode any value other than a-z, A-Z, and 0-9 (there are some exceptions). This is a great approach to ensuring client-side input cannot be interpreted as HTML or JavaScript commands when it is redisplayed in the browser.

ESAPI is under active development and boasts a variety of other security related functionality that may benefit an organization. I encourage everyone to take a look at the ESAPI OWASP project.

The rest of this post is provided as a reference.

Apache Commons Lang StringEscapeUtils Methods:

escapeHtml
escapeJava
escapeJavaScript
escapeSql
escapeXml
unescapeHtml
unescapeJava
unescapeJavaScript
unescapeXml

OWASP Reform Methods:

HtmlEncode
HtmlAttributeEncode
XmlEncode
XmlAttributeEncode
JsString
VbsString

OWASP ESAPI (SVN Snapshot 2008-08-21) Methods:

canonicalize
normalize
encodeForCSS
encodeForHTML
encodeForHTMLAttribute
encodeForJavaScript
encodeForVBScript
encodeForSQL
encodeForLDAP
encodeForDN
encodeForXPath
encodeForXML
encodeForXMLAttribute
encodeForURL
decodeFromURL
encodeForBase64
decodeFromBase64

Legend:
ASCII - The numerical ASCII value
Char - The symbol or character associated with that ASCII value
SEU HTML - org.apache.commons.lang.StringEscapeUtils.escapeHtml
Reform HTML - org.owasp.reform.Reform.HtmlEncode
ESAPI HTML - org.owasp.esapi.Encoder.encodeForHTML
SEU JS - org.apache.commons.lang.StringEscapeUtils.escapeJavaScript
Reform JS - org.owasp.reform.Reform.JsString
ESAPI JS - org.owasp.esapi.Encoder.encodeForJavaScript

ASCII	Char	SEU HTML	Reform HTML	ESAPI HTML	SEU JS	Reform JS	ESAPI JS
0					\u0000	'\x00'	\0
1					\u0001	'\x01'	\x01
2					\u0002	'\x02'	\x02
3					\u0003	'\x03'	\x03
4					\u0004	'\x04'	\x04
5					\u0005	'\x05'	\x05
6					\u0006	'\x06'	\x06
7					\u0007	'\x07'	\x07
8					\b	'\x08'	\b
9					\t	'\x09'	\t
10					\n	'\x0a'	\n
11					\u000B	'\x0b'	\v
12					\f	'\x0c'	\f
13					\r	'\x0d'	\r
14					\u000E	'\x0e'	\x0E
15					\u000F	'\x0f'	\x0F
16					\u0010	'\x10'	\x10
17					\u0011	'\x11'	\x11
18					\u0012	'\x12'	\x12
19					\u0013	'\x13'	\x13
20					\u0014	'\x14'	\x14
21					\u0015	'\x15'	\x15
22					\u0016	'\x16'	\x16
23					\u0017	'\x17'	\x17
24					\u0018	'\x18'	\x18
25					\u0019	'\x19'	\x19
26					\u001A	'\x1a'	\x1A
27					\u001B	'\x1b'	\x1B
28					\u001C	'\x1c'	\x1C
29					\u001D	'\x1d'	\x1D
30					\u001E	'\x1e'	\x1E
31					\u001F	'\x1f'	\x1F
32						' '
33	!	!	!	!	!	'\x21'	\x21
34	"	"	"	"	\"	'\x22'	\"
35	#	#	#	#	#	'\x23'	\x23
36	$	$	$	$	$	'\x24'	\x24
37	%	%	%	%	%	'\x25'	\x25
38	&	&	&	&	&	'\x26'	\x26
39	'	'	'	'	\'	'\x27'	\'
40	(	(	(	(	(	'\x28'	\x28
41	)	)	)	)	)	'\x29'	\x29
42	*	*	*	*	*	'\x2a'	\x2A
43	+	+	+	+	+	'\x2b'	\x2B
44	,	,	,	,	,	','	,
45	-	-	-	-	-	'\x2d'	-
46	.	.	.	.	.	'.'	.
47	/	/	/	/	\/	'\x2f'	\x2F
48	0	0	0	0	0	'0'	0
49	1	1	1	1	1	'1'	1
50	2	2	2	2	2	'2'	2
51	3	3	3	3	3	'3'	3
52	4	4	4	4	4	'4'	4
53	5	5	5	5	5	'5'	5
54	6	6	6	6	6	'6'	6
55	7	7	7	7	7	'7'	7
56	8	8	8	8	8	'8'	8
57	9	9	9	9	9	'9'	9
58	:	:	:	:	:	'\x3a'	\x3A
59	;	;	;	;	;	'\x3b'	\x3B
60	<	<	<	<	<	'\x3c'	\x3C
61	=	=	=	=	=	'\x3d'	\x3D
62	>	>	>	>	>	'\x3e'	\x3E
63	?	?	?	?	?	'\x3f'	\x3F
64	@	@	@	@	@	'\x40'	\x40
65	A	A	A	A	A	'A'	A
66	B	B	B	B	B	'B'	B
67	C	C	C	C	C	'C'	C
68	D	D	D	D	D	'D'	D
69	E	E	E	E	E	'E'	E
70	F	F	F	F	F	'F'	F
71	G	G	G	G	G	'G'	G
72	H	H	H	H	H	'H'	H
73	I	I	I	I	I	'I'	I
74	J	J	J	J	J	'J'	J
75	K	K	K	K	K	'K'	K
76	L	L	L	L	L	'L'	L
77	M	M	M	M	M	'M'	M
78	N	N	N	N	N	'N'	N
79	O	O	O	O	O	'O'	O
80	P	P	P	P	P	'P'	P
81	Q	Q	Q	Q	Q	'Q'	Q
82	R	R	R	R	R	'R'	R
83	S	S	S	S	S	'S'	S
84	T	T	T	T	T	'T'	T
85	U	U	U	U	U	'U'	U
86	V	V	V	V	V	'V'	V
87	W	W	W	W	W	'W'	W
88	X	X	X	X	X	'X'	X
89	Y	Y	Y	Y	Y	'Y'	Y
90	Z	Z	Z	Z	Z	'Z'	Z
91	[	[	[	[	[	'\x5b'	\x5B
92	\	\	\	\	\\	'\x5c'	\\
93	]	]	]	]	]	'\x5d'	\x5D
94	^	^	^	^	^	'\x5e'	\x5E
95	_	_	_	_	_	'\x5f'	_
96	`	`	`	`	`	'\x60'	\x60
97	a	a	a	a	a	'a'	a
98	b	b	b	b	b	'b'	b
99	c	c	c	c	c	'c'	c
100	d	d	d	d	d	'd'	d
101	e	e	e	e	e	'e'	e
102	f	f	f	f	f	'f'	f
103	g	g	g	g	g	'g'	g
104	h	h	h	h	h	'h'	h
105	i	i	i	i	i	'i'	i
106	j	j	j	j	j	'j'	j
107	k	k	k	k	k	'k'	k
108	l	l	l	l	l	'l'	l
109	m	m	m	m	m	'm'	m
110	n	n	n	n	n	'n'	n
111	o	o	o	o	o	'o'	o
112	p	p	p	p	p	'p'	p
113	q	q	q	q	q	'q'	q
114	r	r	r	r	r	'r'	r
115	s	s	s	s	s	's'	s
116	t	t	t	t	t	't'	t
117	u	u	u	u	u	'u'	u
118	v	v	v	v	v	'v'	v
119	w	w	w	w	w	'w'	w
120	x	x	x	x	x	'x'	x
121	y	y	y	y	y	'y'	y
122	z	z	z	z	z	'z'	z
123	{	{	{	{	{	'\x7b'	\x7B
124	\|	\|	\|	\|	\|	'\x7c'	\x7C
125	}	}	}	}	}	'\x7d'	\x7D
126	~	~	~	~	~	'\x7e'	\x7E
127						'\x7f'	\x7F
128	€				\u0080	'\u0080'	\x80
129	�				\u0081	'\u0081'	\x81
130	‚				\u0082	'\u0082'	\x82
131	ƒ				\u0083	'\u0083'	\x83
132	„				\u0084	'\u0084'	\x84
133	…				\u0085	'\u0085'	\x85
134	†				\u0086	'\u0086'	\x86
135	‡				\u0087	'\u0087'	\x87
136	ˆ				\u0088	'\u0088'	\x88
137	‰				\u0089	'\u0089'	\x89
138	Š				\u008A	'\u008a'	\x8A
139	‹				\u008B	'\u008b'	\x8B
140	Œ				\u008C	'\u008c'	\x8C
141	�				\u008D	'\u008d'	\x8D
142	Ž				\u008E	'\u008e'	\x8E
143	�				\u008F	'\u008f'	\x8F
144	�				\u0090	'\u0090'	\x90
145	‘				\u0091	'\u0091'	\x91
146	’				\u0092	'\u0092'	\x92
147	“				\u0093	'\u0093'	\x93
148	”				\u0094	'\u0094'	\x94
149	•				\u0095	'\u0095'	\x95
150	–				\u0096	'\u0096'	\x96
151	—				\u0097	'\u0097'	\x97
152	˜				\u0098	'\u0098'	\x98
153	™				\u0099	'\u0099'	\x99
154	š				\u009A	'\u009a'	\x9A
155	›				\u009B	'\u009b'	\x9B
156	œ				\u009C	'\u009c'	\x9C
157	�				\u009D	'\u009d'	\x9D
158	ž				\u009E	'\u009e'	\x9E
159	Ÿ				\u009F	'\u009f'	\x9F
160					\u00A0	'\u00a0'	\xA0
161	¡	¡	¡	¡	\u00A1	'\u00a1'	\xA1
162	¢	¢	¢	¢	\u00A2	'\u00a2'	\xA2
163	£	£	£	£	\u00A3	'\u00a3'	\xA3
164	¤	¤	¤	¤	\u00A4	'\u00a4'	\xA4
165	¥	¥	¥	¥	\u00A5	'\u00a5'	\xA5
166	¦	¦	¦	¦	\u00A6	'\u00a6'	\xA6
167	§	§	§	§	\u00A7	'\u00a7'	\xA7
168	¨	¨	¨	¨	\u00A8	'\u00a8'	\xA8
169	©	©	©	©	\u00A9	'\u00a9'	\xA9
170	ª	ª	ª	ª	\u00AA	'\u00aa'	\xAA
171	«	«	«	«	\u00AB	'\u00ab'	\xAB
172	¬	¬	¬	¬	\u00AC	'\u00ac'	\xAC
173					\u00AD	'\u00ad'	\xAD
174	®	®	®	®	\u00AE	'\u00ae'	\xAE
175	¯	¯	¯	¯	\u00AF	'\u00af'	\xAF
176	°	°	°	°	\u00B0	'\u00b0'	\xB0
177	±	±	±	±	\u00B1	'\u00b1'	\xB1
178	²	²	²	²	\u00B2	'\u00b2'	\xB2
179	³	³	³	³	\u00B3	'\u00b3'	\xB3
180	´	´	´	´	\u00B4	'\u00b4'	\xB4
181	µ	µ	µ	µ	\u00B5	'\u00b5'	\xB5
182	¶	¶	¶	¶	\u00B6	'\u00b6'	\xB6
183	·	·	·	·	\u00B7	'\u00b7'	\xB7
184	¸	¸	¸	¸	\u00B8	'\u00b8'	\xB8
185	¹	¹	¹	¹	\u00B9	'\u00b9'	\xB9
186	º	º	º	º	\u00BA	'\u00ba'	\xBA
187	»	»	»	»	\u00BB	'\u00bb'	\xBB
188	¼	¼	¼	¼	\u00BC	'\u00bc'	\xBC
189	½	½	½	½	\u00BD	'\u00bd'	\xBD
190	¾	¾	¾	¾	\u00BE	'\u00be'	\xBE
191	¿	¿	¿	¿	\u00BF	'\u00bf'	\xBF
192	À	À	À	À	\u00C0	'\u00c0'	\xC0
193	Á	Á	Á	Á	\u00C1	'\u00c1'	\xC1
194	Â	Â	Â	Â	\u00C2	'\u00c2'	\xC2
195	Ã	Ã	Ã	Ã	\u00C3	'\u00c3'	\xC3
196	Ä	Ä	Ä	Ä	\u00C4	'\u00c4'	\xC4
197	Å	Å	Å	Å	\u00C5	'\u00c5'	\xC5
198	Æ	Æ	Æ	Æ	\u00C6	'\u00c6'	\xC6
199	Ç	Ç	Ç	Ç	\u00C7	'\u00c7'	\xC7
200	È	È	È	È	\u00C8	'\u00c8'	\xC8
201	É	É	É	É	\u00C9	'\u00c9'	\xC9
202	Ê	Ê	Ê	Ê	\u00CA	'\u00ca'	\xCA
203	Ë	Ë	Ë	Ë	\u00CB	'\u00cb'	\xCB
204	Ì	Ì	Ì	Ì	\u00CC	'\u00cc'	\xCC
205	Í	Í	Í	Í	\u00CD	'\u00cd'	\xCD
206	Î	Î	Î	Î	\u00CE	'\u00ce'	\xCE
207	Ï	Ï	Ï	Ï	\u00CF	'\u00cf'	\xCF
208	Ð	Ð	Ð	Ð	\u00D0	'\u00d0'	\xD0
209	Ñ	Ñ	Ñ	Ñ	\u00D1	'\u00d1'	\xD1
210	Ò	Ò	Ò	Ò	\u00D2	'\u00d2'	\xD2
211	Ó	Ó	Ó	Ó	\u00D3	'\u00d3'	\xD3
212	Ô	Ô	Ô	Ô	\u00D4	'\u00d4'	\xD4
213	Õ	Õ	Õ	Õ	\u00D5	'\u00d5'	\xD5
214	Ö	Ö	Ö	Ö	\u00D6	'\u00d6'	\xD6
215	×	×	×	×	\u00D7	'\u00d7'	\xD7
216	Ø	Ø	Ø	Ø	\u00D8	'\u00d8'	\xD8
217	Ù	Ù	Ù	Ù	\u00D9	'\u00d9'	\xD9
218	Ú	Ú	Ú	Ú	\u00DA	'\u00da'	\xDA
219	Û	Û	Û	Û	\u00DB	'\u00db'	\xDB
220	Ü	Ü	Ü	Ü	\u00DC	'\u00dc'	\xDC
221	Ý	Ý	Ý	Ý	\u00DD	'\u00dd'	\xDD
222	Þ	Þ	Þ	Þ	\u00DE	'\u00de'	\xDE
223	ß	ß	ß	ß	\u00DF	'\u00df'	\xDF
224	à	à	à	à	\u00E0	'\u00e0'	\xE0
225	á	á	á	á	\u00E1	'\u00e1'	\xE1
226	â	â	â	â	\u00E2	'\u00e2'	\xE2
227	ã	ã	ã	ã	\u00E3	'\u00e3'	\xE3
228	ä	ä	ä	ä	\u00E4	'\u00e4'	\xE4
229	å	å	å	å	\u00E5	'\u00e5'	\xE5
230	æ	æ	æ	æ	\u00E6	'\u00e6'	\xE6
231	ç	ç	ç	ç	\u00E7	'\u00e7'	\xE7
232	è	è	è	è	\u00E8	'\u00e8'	\xE8
233	é	é	é	é	\u00E9	'\u00e9'	\xE9
234	ê	ê	ê	ê	\u00EA	'\u00ea'	\xEA
235	ë	ë	ë	ë	\u00EB	'\u00eb'	\xEB
236	ì	ì	ì	ì	\u00EC	'\u00ec'	\xEC
237	í	í	í	í	\u00ED	'\u00ed'	\xED
238	î	î	î	î	\u00EE	'\u00ee'	\xEE
239	ï	ï	ï	ï	\u00EF	'\u00ef'	\xEF
240	ð	ð	ð	ð	\u00F0	'\u00f0'	\xF0
241	ñ	ñ	ñ	ñ	\u00F1	'\u00f1'	\xF1
242	ò	ò	ò	ò	\u00F2	'\u00f2'	\xF2
243	ó	ó	ó	ó	\u00F3	'\u00f3'	\xF3
244	ô	ô	ô	ô	\u00F4	'\u00f4'	\xF4
245	õ	õ	õ	õ	\u00F5	'\u00f5'	\xF5
246	ö	ö	ö	ö	\u00F6	'\u00f6'	\xF6
247	÷	÷	÷	÷	\u00F7	'\u00f7'	\xF7
248	ø	ø	ø	ø	\u00F8	'\u00f8'	\xF8
249	ù	ù	ù	ù	\u00F9	'\u00f9'	\xF9
250	ú	ú	ú	ú	\u00FA	'\u00fa'	\xFA
251	û	û	û	û	\u00FB	'\u00fb'	\xFB
252	ü	ü	ü	ü	\u00FC	'\u00fc'	\xFC
253	ý	ý	ý	ý	\u00FD	'\u00fd'	\xFD
254	þ	þ	þ	þ	\u00FE	'\u00fe'	\xFE
255	ÿ	ÿ	ÿ	ÿ	\u00FF	'\u00ff'	\xFF

SAML Research Road Map

2008-08-07T09:18:00.024-05:00

Recently, I have been asked by several people about SAML as it pertains to single sign-on for web applications. At the time, I was not familiar with this standard or the technology surrounding it and decided to do some research. I discovered there were a lot of valuable resources on the web, but there was not an easy to understand road map describing the order in which to read these items.

This article is an attempt to provide that road map, so others can understand and appreciate SAML.

Note: This article pertains to SAML 2.0 and not SAML 1.x.

Introduction

From the OASIS SAML Technical Overview Document:

“The OASIS Security Assertion Markup Language (SAML) standard defines an XML-based framework for describing and exchanging security information between on-line business partners.”

While this description makes sense to those already familiar with SAML, it may be incomprehensible to everyone else. To help everyone else, I’m going to provide a simplified, high-level overview. Then, once some of the basics have been established, I will provide a resource from the OASIS site that describes the technical details of the SAML standard.

High-level Overview

The SAML standard can be broken down into several components, some of which are listed below.

SAML Assertions
SAML Protocols
SAML Bindings
SAML Profiles

SAML Profiles or Use Cases

SAML Profiles are a collection of SAML components organized into use cases suited to solve a business problem or need. Examples of major profiles or use cases defined within the SAML Standard are listed below.

Web Browser Single Sign-On Profile (Web Browser SSO)
Single Logout Profile
Web Services Security (WS-Security) and SAML

The goal of the Web Browser SSO profile is to provide a single sign-on experience for users to move seamlessly between web applications of disparate organizations or companies. For example, if three distinct companies providing complimentary services (such as a hotel booking, flight booking, and car rental service) wish to form a partnership, they can create a single sign-on experience for their users (and share information) without the consolidation of servers or data.

The Single Logout Profile provides a mechanism to simultaneously log a user out of all sites participating in a particular single sign-on experience.

The combination of WS-Security and SAML is actually an extension of SAML and not directly defined as a profile. However, this use case is a valuable way to use SAML as a security token for authentication and authorization of a principle interacting with a system through SOAP web services.

SAML Assertions

SAML Assertions consist of XML data that contains authentication, authorization, or additional attributes about a principal (a user, application, or other subject wishing to access a resource). SAML assertions are often provided by an identity provider or authentication service to a service provider. The service provider can understand the Assertions and trusts the identity provider due to agreements made between the organizations that own or operate the services.

An example assertion is shown below. Discussion of the structure of a SAML Assertion will be addressed by a resource provided later in this article.

SAML Protocols

SAML Protocols define mechanisms for communicating SAML Assertions between identity providers, principals, and service providers. The standard provides a detailed set of request and response strategies to suit a variety of business and technical requirements.

SAML 2.0 includes the following protocols:

Assertion Query and Request Protocol
Authentication Request Protocol
Artifact Resolution Protocol
Name Identifier Management Protocol
Single Logout Protocol
Name Identifier Mapping Protocol

An example request and response is shown below. Discussion of the SAML Protocol sequences and the structure of the request and response below will be addressed by a resource provided later in this article.

SAML Protocol Authentication Request:

SAML Protocol Authentication Response:

SAML Bindings

SAML Bindings determine how SAML messages are encapsulated within other protocols such as HTTP or SOAP. SAML 2.0 describes the following bindings:

SAML SOAP Binding
Reverse SOAP (PAOS) Binding
HTTP Redirect (GET) Binding
HTTP POST Binding
HTTP Artifact Binding
SAML URI Binding

Next Step

Now that a basic understanding of SAML has been established, I suggest reading the Security Assertion Markup Language (SAML) V2.0 Technical Overview. This document is written by OASIS and summarizes the SAML standard in a way that is easy to understand.

What About Security?

There are many security considerations that must be analyzed before the implementation of a product leveraging SAML takes place. Often authentication or authorization information is allowed to pass through untrusted users or may be intercepted by attackers. The Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0 document provides a detailed discussion of these issues and appropriate mitigation techniques.

If I was asked to summarize the mitigation strategies described in this document, I would provide the following recommendations:

Use TLS/SSL 3.0 with strong ciphers and verifiable certificates (usually for just the server, but sometimes needed for the client as well).
If the application must ensure data integrity remains intact, use XML Signature to ensure it is not manipulated while in transit.
If confidential, sensitive, or private data passes through the client use XML Encryption to ensure it is not disclosed to unauthorized parties.

Threat Modeling as the Only Secure Development Activity

2008-08-06T20:36:00.022-05:00

Purpose

This article discusses why it is important for threat modeling to be supported by a full secure development process within an organization. If threat modeling is the only secure development activity performed, it will be difficult to identify threats, mitigate risks, and leverage knowledge gained during threat modeling efforts in future projects.

This article does NOT describe how to perform threat modeling, however it does provide a brief introduction to ensure it is clear what the author means by the term "threat modeling."

Introduction to Threat Modeling

At its core, threat modeling is a secure development activity in which developers, architects, designers, security personnel, and sometimes managers consider possible attack scenarios or threats against an application. This process typically occurs during a planning or design phase of development before any code is written.

One threat modeling strategy may include the following steps:

1. Resource <- 2. Capability <- 3. Use Case <- User
1. Resource <- 2. Capability <- 4. Threats <- Attacker

Identify resources within the application, such as database tables, file systems, and application servers.
Determine the capabilities or actions that can be performed on each item. One example for a database table may be to read checking account transaction data.
Consider the proper way in which a valid user may invoke a capability. Following with the previous example, a customer may login to Online Banking and access their checking account details.
Consider the threats to a particular resource based on the associated capabilities. Threat modeling participants can base threats on defined use cases or by brainstorming in a free form manner. Example: An attacker may wish to access another user's checking account data.
Assign a risk level to each threat, such as high, medium, and low.
Define countermeasures based on the analysis of the risk level vs. the cost of implementing the solution

There are many ways threat modeling can be performed. For more information, please visit the OWASP Threat Modeling page.

Threat Modeling as the Only Secure Development Activity

Threat modeling is a necessary component within a secure development process. However, if threat modeling is the only security activity your organization has implemented, you may not be realizing its full value or potential.

During the threat modeling process, threats and countermeasures must be defined. Typically, it is difficult for threat modeling participants to think from an attacker's perspective without basic application security awareness training. Often, the end result will be an incomplete threat model that does not include enough of the relevant application attack scenarios or threats.

Once threats have been enumerated, participants must identify viable and effective countermeasures. The most effective countermeasures are those based on application security best practices. Often, developers are not familiar with these best practices leading to the creation of countermeasures that only partial protect resources. Security training is necessary to provide application security knowledge and these essential best practices.

Once appropriate countermeasures have been designed, implemented, and tested to ensure they are complete and effective solutions for eliminating risks, this knowledge should be captured to be reused in future projects. If this knowledge is not captured, the organization will be forced to start from scratch each and every time threat modeling is performed. This can be an unnecessary allocation of time or money.

To effectively capture and reuse this knowledge, an organization should wrap security best practices and solutions into the organization's security policies and secure coding standards. In future projects, the designer or requirements specifier can create security requirements based on this documentation. During the threat modeling process, threats can be matched up with defined security requirements allowing participants to focus on threats that have not been mitigated in past efforts.

Conclusion

Threat modeling should not be the only secure development activity used within an organization. It must be supported by a full process including security training, security policies, secure coding standards, and many more activities. The OWASP Comprehensive, Lightweight Application Security Process is one fully featured secure development process that should be considered.

OWASP CLASP Overview Presentation

2008-08-06T16:05:00.014-05:00

The OWASP Comprehensive, Lightweight Application Security Process (CLASP) is an "Activity driven, role-based set of process components whose core contains formalized best practices for building security into your existing or new-start software development life cycles in a structured, repeatable, and measurable way"

In other words, it is one method of many (others examples are Microsoft SDL and Software Security Touchpoints) for implementing a secure development process.

A couple months ago, I created a presentation that gave a high-level overview of CLASP. I wanted to make this presentation available to the community as well as gather input from industry practitioners regarding how feasible this model is within their environment. I encourage anyone who is interested to join the OWASP CLASP mailing list or comment directly.

The presentation can be found here: OWASP CLASP Overview

Nick Coblentz

Security and Development: Building A Better Relationship

Web Application Vulnerability Unit Testing Cheat Sheet (Capybara and Watir-WebDriver)

Using Watir-WebDriver or Capybara For Web Application Vulnerability Unit Testing

Security Testing Roles - Expanding on Integrating Security Testing into the QA Process

Integrating Security into the QA Process

Security B-Sides Kansas City Presentation

Potential BlackBerry Playbook Application Permissions Vulnerability - Need Help Confirming

OWASP AppSec Ireland and DC

Rails 3 HTML Encodes by Default

OWASP AppSec Research 2010 Stockholm Conference Videos Posted!

OWASP AppSec Research 2010 Pictures

Aula Magna (Conference Venue)

Track 1

Day 1 Keynote with Chris Evans, Google

Day 2 Keynote with Steve Lipner, Microsoft

Gala Dinner at Stockholm City Hall

Conference Closing Remarks and Thanks

I'm Presenting at OWASP AppSec Research 2010 Conference

.NET User Group Presentation - Microsoft SDL-Agile

Reducing Information Disclosure in WCF Data Services

Reducing Information Disclosure in ASP.NET Web Services

How Often Should I Reassess My Web Applications?

Microsoft SDL-Agile Presentation Slides

OWASP Presentation on Dec. 10: Microsoft SDL-Agile

Microsoft SDL for Agile Development

Observed Secure Software Development Stages

Turn Application Assessment Reports into Training Classes

AT&T Acquires VeriSign's Global Security Consulting Business

Using Microsoft's AntiXSS Library 3.1

Flash Remoting Support in Burp Suite Pro

Amazon EC2 and PCI Compliance

Vulnerability Tracking, Workflow, and Metrics With Redmine

Internal AppSec Portals: Resources

Internal AppSec Portals: Introduction

*Repost* Web Application Security Portfolios

SAMM Inteview Template Version 1.0

Preparing For a Third Party Application Assessment

Microsoft SDL Process Template

Secure Development Jump Start

ISSA Journal: Web Application Security Portfolios

Struts 2 Security Addons Code Repository

Light-weight Code Review as You Program (Not After You're Done)

OWASP ISWG: Struts 2/WebWork Gap Analysis

OWASP's SQL Injection Prevention Cheat Sheet

Software Assurance Maturity Model 1.0 Released

Cloud Computing Data Security

Mosso - First PCI Compliant Customer Through Self Evaluation and Scanning

PCI Compliance and Cloud Computing

Create a Security Strategy Before Utilizing Cloud Computing

OWASP's XSS Prevention Cheat Sheet

Page-Level Access Controls in Struts 2 - Part 2

Page-Level Access Controls in Struts 2 - Part 1

CSRF Prevention in Struts 2

Custom Error Pages in Struts 2

SSL/TLS in Struts 2

HTTP Caching Headers in Struts 2

JSESSIONID Regeneration in Struts 2

Ubiquity Security Concerns Part 1: An Introduction

Presentation Layer Output Encoding: Apache Commons Lang StringEscapeUtils vs. OWASP Reform

SAML Research Road Map

Threat Modeling as the Only Secure Development Activity

OWASP CLASP Overview Presentation

Repost Web Application Security Portfolios