Web Admin Blog Real Web Admins. Real World Experience.


Building a Source Code Analysis Tool for Security Consultants – OWASP AppSec NYC 2008

This presentation was by Dinis Cruz, and OWASP board member and he works for Ounce Labs, a producer of a source code analysis tool, but he said he was not speaking on behalf of either.  The presentation was entitled "Building a Tool for Security Consultants: A Story of a Customized Source Code Scanner".  Everything was built on Open Source except for the scanning engine which is using Ounce.

About the Tool

Developed features while performing an assessment.  Only developing features that make sense.  Considered mature after 4 or 5 engagements with no feature additions necessary.  Tools job should be to give you "pointers" that you can follow.  Tool displays a chart of the flow from function to function.  Uses different colors to represent data sources and data sinks.  Can map just source to sink so you can easily figure out where tainted data arrives from and where it goes to.  Able to look for "insecure patterns" instead of finding 20 XSS or 10 SQL injection pages.  Able to display function calls ordered both ways: what functions are called by a function or functions that call a function.  Added a scripting editing environment.  Everything that is available via the GUI can be scripted.

There were no slides for this presentation and the whole thing was a demonstration of the tool and how it works, it's features, etc.  I don't know a whole lot about source code scanning and will tell you that a good chunk of this presentation was over my head, but Dinis was very enthusiastic about the tool and made it sound like it's something totally awesome and very worth looking into.  He says that the tool is not "nice" and not "easy to use", but once you get used to it, it is an extremely useful tool for source code analysis.


Coding Secure with PHP – OWASP AppSec NYC 2008

This presentation was by Hans Zaunere, Managing Member, and it is entitled "PHundamental Security - Ecosystem Review, Coding Secure with PHP, and Best Practices".  Take a look at http://www.nyphp.org/phundamentals/ for the ongoing guide and best practices.  Guru Stefan Esser recently presented an excellent talk at Zendcon.

Security fundamentals are common across the board.  Different environments have different requirements (desktop apps different from web/internet apps).  Web/internet have a huge number of touch points.  PHP isn't responsible for all of them, but the developer is.  Different languages handle in different ways.  PHP is no different except "More internet applications speak PHP than any other".  PHP gets a bad rap.  Low point of entry and great flexibility.  There's been some mistakes like weak default configuration, too forgiving for amateurs, the infamous magic_* of PHP, PHP Group argues what's a security flaw.

It's easy to shoot yourself in the foot with C.  In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg. - Bjarne Stroustrup, Inventor of C++

Three zones of responsibility.  PHP is effectively a wrapper around libraries and data sources.  Many external dependencies and touch points.

  1. Poorly written code by amateur developers with no programming background.  Primary cause for the security ecosystem around PHP.  Laziness - letting PHP do it's magic_*.  "Program smart"
  2. Extensions and external libraries.  PHP's greatest asset.  Sometimes library binding is faulty.  Sometimes the external library has faults, or behaves in an unforeseen way when in a web environment - possible in any environment.  Know what extensions you're using, use the minimal number of extensions, and be aware of the environment they were originally designed for.  "Know thy extensions"
  3. PHP Core - "PHP".  Secunia says 19 advisories for PHP between 2003-2008.  Java had 38+ and Ruby 11+.  "The list goes on - PHP is not alone".  One advisory in 2008.  "More internet applications speak PHP than any other"

Best Practices

  • Best practices are common to any well run enterprise environment.  PHP is growing into this environment very quickly.
  • Web security is largely about your data and less about exploits in the underlying platform.  Buffer overflows aren't so much the hot-topic.
  • Installation - Avoid prepackaged installs, including RPMs, .deb, etc.  If you use them, review their default deployment.  Installation touch points also typically include MySQL/Apache.
  • Configuration - Use php.ini-recommended.  Better yet, take the time to know what you're doing and tune configuration files yourself.
  • Don't make PHP guess what you mean.  Be explicit with variables and types.  Don't abuse scope - know where your variables come from.  Avoid magic_* and implicitness - BE EXPLICIT.
  • Keep code small, organized, and maintainable.  Use OOP techniques to enforce code execution paths.  Use includes to keep things organized.
  • Don't use super-globals directly - wrap for protection.

Be aggressive - B.E. aggressive

  • It's always about data
  • One of PHP's greatest strengths - loosely typed.  Also it's biggest weakness.  Don't make PHP guess what you mean.
  • Cast variables, know their type and the data you expect.  Let PHP do it's magic only when you want it to - not by chance.
  • Keep tabs on your data's path, lifecycle and type.  Know where it's come from, what it's doing, and where it's going.  Filter/escape/cast and throw exceptions every step of the way.
  • Input validation, output validation, CASTING.
  • Don't be lazy, be explicit, use OOP.

Casting isn't just for movie producers

  • No system has a single security pressure point
  • Don't take the easy way out just because you can
  • Put PHP in the same well managed enterprise environment as other technologies
  • PHP/AMP respond very well to TLC


PHP is just part of the ecosystem and there is awareness and experience on the PHP side.  The ying/yang of PHP's history overshadows reality.  Stand by PHP and it'll stand by you.  Web/internet applications are deep and complex.  Users, interoperability, data, architecture, support, compliance.  Phishing, hijacking, spam, sopcial engineering - BROWSERS!

PHP is the least of your worries


Mastering PCI Section 6.6 – OWASP AppSec NYC 2008

This presentation is by Jacob West in the Security Research Group and Taylor McKinsley in Product Marketing from Fortify software.  I'd like to note that Fortify is a developer of a source code analysis tool and so this presentation may have a bias towards source code analysis tools.

56% of organizations fail PCI section 6.  Poorly coded web applications leading to SQL injection vulnerabilities is one of hte top five reasons for a PCI audit failure.  Section 6 is becoming a bigger problem: #9 in 2006 reason for failure, #2 in 2007.

PCI Section 6 has to do with guidelines to "Develop and maintain secure systems and applications".  Section 6.6 reads "Ensure that all web-facing applications are protected against known attacks by either of the following methods: Having all custom application code reviwed for common vulnerabilities by an organization that specializes in web application secure" or by using a web application firewall.  Further clarifications say that automated tools are acceptable, web application penetration testing is allowed, and vulnerability assessments can be performed by an internal team.

Comparing Apples, Oranges, and Watermelons

  • Setup: Source code analysis (+2) is good because it works on existing hardware, but must live where your source code lives.  Penetration testing (+3) is good because you only need one to assess everything and works on existing hardware, but needs to talk to a running program.  Application firewall (+1)is good because it lives on the network, but you must model program behavior.
  • Optimization: Source code analysis (+2) is good because you can specify generic antipatterns in code, but you must understand vulnerability in detail.  Penetration testing (+2) is good because tests are attacks, but you must successfully attack your application.  Application firewalls (+1) are good because they share configuration across programs, but must differentiate good from bad.
  • Performance: Source code analysis (+3) is good because it simulates all application states and is non-production, but scales with build time and not the number of tests.  Penetration testing (+2) is good because you get incremental results and is non-production, but you must exercise each application state.  Application firewall (+1) is good because it's a stand-alone device and scales with $$$, but impacts production performance and scales with $$$.
  • Human resources: Source code analysis (+1) is good because it enables security in development and reports a root cause, but makes auditors better and does not replace them.  Penetration testing (+2) is good because it is highly automatable, but reports symptoms and not the root cause.  Application firewall (+2) is good because once it's configured it functions largely unattended, but requires extensive and ongoing configuration.
  • Security know-how: Source code analysis (+3) is good because it gives code-level details to an auditor, but you must understand security-relevant behavior of APIs.  Penetration testing (+1) is good because it automates hacks, but a hacker is required to measure success and optimize.  Application firewall (+2) is good because it identifies common attacks out of the box and is a community effort, but a hacker is required to measure success and customize.
  • Development expertise: Source code analysis (+1) is good because it focuses attention on relevant code, but you must understand code-level program behavior.  Penetration testing (+2) is good because basic attacks ignore internals, but advanced attacks require internal knowledge.  Application firewalls (+2) are good because they live on the network, but you must understand the program to tell good from bad.
  • False positives: Source code analysis (+1) is good because it gives auditors details to verify issues, but reports impossible application states.  Penetration testing (+2) is good because results come with reproduction steps, but it is difficult to oracle some bugs.  Application firewalls (+1) are good because it is attacks instead of vulnerabilities, but there is an evolving definition of valid behavior.
  • False negatives: Source code analysis (+3) is good because it simulates all program states and models the full program, but it must be told what to look for.  Penetration testing (+1) is good because it is good at finding what hackers find, but is difficult to oracle some bugs and has missed coverage.  Application firewalls (+1) are good because it uses attacks instead of vulnerabilities, but there is an evolving attack landscape.
  • Technology support: Source code analysis (+2) is good because parsing is separable from the analysis and is interface-neutral, but it must adapt to new program paradigms.  Penetration testing (+2) is good because it is independent from program paradigms, but is tied to protocols and is limited to network interfaces.  Application firewalls (+2) are good because they are independent from program paradigms, but are tied to protocols and are limited to network interfaces.

Working Towards a Solution

  • Assessment: Proving the problem or meeting the regulatory requirement.  Recurring cost that does not "fix" anything
  • Remediation: Fixing security issues found during assessments.  Lowering business risk at a single point in time.
  • Prevention: Get security right hte first time.  Minimizing business risk systematically.

Do your own comparison and fill out the scorecard yourself (presenters ratings are noted in parentheses above).

Taylor did interviews with three companies to get their experiences deploying each (source code analysis, penetration testing, and application firewall) and had them evaluate based on the nine criteria both before and after buying.  Not going to list each company's results in the blog, but it was just a basic table with each criteria and a number rating for both before purchase and after deployment.  To sum it up, Source Code Analysis was a 14 rating before purchase and a 17 rating after deployment.  Penetration testing was a 21 rating before purchase and a 21 rating after deployment.  Application firewalls were a 21 rating before purchase and a 16 rating after deployment.  It seems like the first organization had a large amount of developers and that factored into their decision to purchase a source code analysis tool.  The second organization had a far fewer number of developers and was more of an IT shop and chose the penetration testing tool.  The last organization was a smaller shop in general (still fairly large) and went with the WAF because they wanted something they could just put in place and manage.

Analysis: All three solutions required more effort than expected.  All three solutions produce reasonably accurate results.  Varying levels of expertise needed.

How do you demonstrate that your application is protected against known attacks?

  • Verification that the application was analyzed
  • A report showing no critical security issues identified
  • Document showing how the tool fits into your architecture

How do you show that the user is appropriately trained?

  • Document explaining prior experience or an informal interview

How do you show that you have configured the tool appropriately?

  • Document explaining how the tool was configured and what new rules had to be added.

Summary: PCI section 6 is evolving to become increasingly precise.  Compare technologies in your environment along nine criteria.  Demonstrating compliance is an art, not a science.


Enterprise Security API – OWASP AppSec NYC 2008

This presentation was by Jeff Williams, OWASP Chair, on the Enterprise Security API.

Vulnerabilities and Security Controls

  • Missing - 35%
  • Broken - 30%
  • Ignored - 20%
  • Misused - 15%

Goal is to enable developers.  Need to give them hands-on training, a secure coding guideline, and an Enterprise Security API.

The problem with Security Libraries: overpowerful, incomplete, not integrated, broken, can't update, custom.

Enterprise Security API (ESAPI) includes authentication, user, AccessController, AccessReferenceMap, Validator, ENcoder, HTTPUtilities, Encryptor, EncryptedProperties, Randomizer, Exception Handling, Logger, IntrusionDetection, and SecurityConfiguration.  Built on top of your existing enterprise services or libraries.

Some Examples

  1. Input Validation - validation engine and decoding engine that will take input and provide safe output for web pages
  2. Output Encoding - need to use the right encoding for the right place you are putting the encoding
  3. Authentication - creates a user object and functions to login() or logout().  Provides additional functionality for encrypted cookies, changing SESSIONID, remember me cookies, etc.
  4. Access Control - provides functionality to check if a user is authorized for URLs, functions, data, services, or files.
  5. Direct Object Reference Protection - use an access reference map that does an indirect translation between an object and it's reference.  Use getDirectReference() and getIndirectReference() functions.
  6. Error, Logging, and Detection - Configurable thresholds.  Responses are log intrusion, logout user, and disable account.  User object is available anywhere in the application so the logger links the messages logged to a user.  Exceptions sent to an intrusion detector which has thresholds set.

OWASP ESAPI Covers Majority of OWASP Top Ten

  • A1. XSS - Validator, Encoder
  • A2. Injection Flaws - Encoder
  • A3. Malicious File Execution - HTTPUtilities (Safe Upload)
  • A4. Insecure Direct Object Reference - AccessReferenceMap, AccessController
  • A5. CSRF - User (CSRF TOken)
  • A6. Leakage and Improper Error Handling - EnterpriseSecurityException, HTTPUtils
  • A7. Broken Authenticationa nd Sessions - Authenticator, User, HTTPUtils
  • A8. Insecure Cryptographic Storage - Encryptor
  • A9. Insecure Communications - HTTPUtilities (Secure Cookie, Channel)
  • A10. Failure to Restrict URL Access - AccessController

MITRE found that all application security tool vendors' claims put together cover only 45% of the known vulnerability types (695).  They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true).  This means that at least 55% is not covered by tools.

Latest version released in September 2008 (1.3.1) and are holding a summit later this year to determine if they got everything right.  In active development.  Java, .NET, PHP, classic ASP.  Rich client extensions.  Web service extensions.  Framework (Struts) integration.

Written under the BSD license so it should be very easy for you to use it in your applciations.

Project Home Page: http://www.owasp.org/index.php/ESAPI

Expert advisory/design/implementation team that has collectively reviewed over 100 million lines of code.  ~600 JUnit test cases.  FindBugs, PMD, Ounce, and Fortify clean.  Code review by several Java security experts.  Penetration test of sample applications.  Full Javadoc for all functions.

Presentation will be posted on homepage.  Includes a list of banned API's that ESAPI replaces.  Has example of enterprise cost savings.  All of ESAPI is only 5000 lines of code.  Building a ESAPI swingset which has a demo of insecure (what can go wrong) and secure (using ESAPI) programming and good tutorial on how to use.  Login module shows last successful login, last failed login, number of failed logins, enforces a strong password policy.


Top 10 Strategies to Secure Your Code

Since Michael Howard moved from Redmond to Austin, I've had the privilege to see him present several times now. This is the guy who literally wrote the book on writing secure code and the secure development lifecycle. He is a fantastic speaker and I'd highly recommend checking him out if you every get the opportunity. Yesterday, I heard that he was speaking on securing your code at the San Antonio OWASP meeting so I decided it was worth making the drive down to see his presentation. So, I give to you Michael Howard's Top 10 Strategies to Secure Your Code straight out of one of his Microsoft TechNet presentations.

Michael began by giving us the definition of a secure system. He said "A secure system does what it's supposed to do and no more." It's such a simple concept, but in practice such a hard thing to achieve. Here are his suggestions on how to accomplish that: