christopher bischoff's List: AppSec

• I have always believed that in order for security to become an inherent part of software development it must come from within the development community itself.

   

   

  We can’t have security people who know development. We must have developers who know security. There is a fundamental difference and it is important.
• Cenzic as an example. This is a firm that was founded by the same people that founded HB Gary. Yes the same firm that has been exposed to have been plotting a campaign to discredit wiki-leaks. Cenzic also have a patent for web fuzzing. Now I am not a lawyer but this patent appears that it could be applied against OWASP projects like WebScarab at any time. This is the same firm that used to claim in their marketing that they scan for the OWASP Top Ten. Thats right using HTTP they scanned for insecure crypto! These are my personal opinion but this is not a firm with good ethics yet is actively involved in OWASP.
• Where is the advice on writing security related BDD tests, integrating security into Agile, tools that plug into CI servers and IDE’s ?
• Software Security is for developers and Application Security is for security people. The first persona is the builder and the second persona the breaker. One is concerned with assessing security posture and the other architecting and creating secure software.

2 more annotations...

• BSIMM and touchpoints do not go down and dirty to figure out how to actually make software secure.
  

  And frankly, that’s what the entire world really needs right now.

   

   

   

   

• Injection attacks are one of the most common severe attacks a website could face and security professionals tend to prescribe input validation when output encoding is more appropriate. When passing on data to other sources (the client, a database, other servers), transferring it via a safe method in a sanitized form is the optimal way to go. Input validation in this instance is sub-optimal.

• AppSec Manifesto
   
  • Developers are not lazy, rather quality oriented ⇒ Insecure applications do not stem from laziness.
   
  • Features and functions are always more important than security ⇒ Security should enable more features and functions.
   
  • Responsible disclosure is a good way of achieving more secure applications ⇒ Hackers are needed.
   
  • Technology is a crucial part of security ⇒ Therefore I keep coding.
   

• any category of web application injection attacks, most folks in the field almost instinctively begin talking about "input validation". Sure, input validation is important when it comes to detecting certain attacks, but encoding of user-driven data (either before you present that data to another user, or before you use that data to access various services) is actually a great deal more important for truly stopping almost any class of web application injection attack.
• While input validation is still crucial for a defense-in-depth application security coding practice; it's truly the encoding of user data that becomes your final and most important line of defense against XSS, SQL Injection (PreparedStements and binding of variables actually encoding user-driven data specific to each database vendor via the Java JDBC driver), LDAP injection, or any other class of injection attack.
• I like " Input Validation - Important for yourself; Output Encoding - Important for everyone else" even if the title is a bit longer
• Input Validation from a business functionality perspective, is indeed very important. But from a security perspective? I do not its as security-critical as most in the industry believe.
• make the mistake of validating their xml data and data elements, but never encode before accessing a back-end service leaving them vulnerable to a large class of attacks.
• authorization attacks, I feel that account lockout, strong passwords, and secure user administration is more important than input validation.

4 more annotations...

• Many web sites have SQL-injection and XSS (Cross Site Scripting) vulnerabilities, and security articles often mention lack of input validation as the reason for these problems. This isn't necessarily correc
• The metacharacter problem
  Both SQL-injection and XSS are metacharacter problems. A metacharacter is a control character used in a part of the system to control the display or flow of data. These problems occur every time a system communicates with a system of a different flavour, be it a browser, a database or a legacy system.
• Why input validation can fail to solve these problems
  Consider a blogging system allowing users to post comments to the entries. While this is a simple system, it contains enough functionality for me to explain. The blogging system has a comment form containing the fields: name, e-mail, headline and comment body.
  
  Let's start out with the name field. To avoid getting XSS or SQL injection, input validation needs to block out any letters which are not used in a name. Using best practice, we create a white list of allowed values. While creating this white list would be easy if all names had the same format ("Joe Smith"), a problem arises when Conan O'Brian comes along. The ' in his name is a SQL control character and can also be used for strings in javascript or HTML tags. So how do we handle this using input validation. We have to allow this character. We also have to allow foreign names which do not necessarily follow standard formats
• The solution
  Don't get me wrong. I still think input validation should be present in every application. But to avoid metacharacter problems, data needs to be escaped when it leaves the system, not when it enters it. This means that the web application needs to escape data just before sending it to the database (preferably by using prepared statements) or a legacy system. Data presented on an HTML page needs to be escape when it's written to the HTML page. And best practice for escaping should be "Escaping by default", which means you need a reason if you are printing unescaped data.

2 more annotations...

• Advocating input validation as the first line of defense against injection vulnerabilities is like Microsoft forbidding users from typing “for”, “if”, or “while” in Office Word in fear that a victim could execute arbitrary code by feeding a Word document to a compiler. It’s like preventing race conditions by carefully avoiding to spawn any threads, or preventing buffer overflows by ensuring that all buffers are “kept small”.
• Injection vulnerabilities – i.e. those nifty vulnerabilities like cross-site scripting (XSS), SQL injection, XPath injection, OS command injection, and so on – are caused by one simple thing: the dumbness of a developer not seeing that he’s using one channel (i.e. an HTML page, or a SQL query) to convey two types of content (i.e. rendering directives and text content, or SQL statements and literal parameters).
• developer knows this and makes sure that the two messages are kept separate by encoding the one that’s supposed to be encoded. A dumb (or lazy) developer doesn’t and ends up mixing things up. When the lazy developer concatenates strings to build HTML and forgets to HTML-encode the text in order to avoid it being parsed as rendering directives, what’s the bug? Is it lack of encoding, as plain software engineering thinking would suggest, or is it “bad, nasty, malicious input”, as most security consultants keep swearing?
• t’s always better to use white-listing, because the worse that can happen is that all your users from Ireland, Italy, Spain, France, Germany, and any other country that uses characters other than those 26 you shoved in your white-list regular expression will be cut off from your Web app. Better safe than sorry, dude. Never mind that I lost a few million customers.
• The safe course is to use validation and escaping together to minimize the risk that you end up with XSS and other forms of injection. Of course, if a parameterized interface is available then you should absolutely use that instead of escaping.

3 more annotations...

• We belong at level six and unless we appreciate and understand how security fits in with functions, performance, usability, uptime, and maintainability we will keep being ignored by developers
• a featureless system is useless. A security feature that hits performance notably is out. A system with poor usability will bring no business so usability is above security. "Uptime, hey that's a security thing!" No. Just because DoS attacks hit your uptime doesn't mean we own the issue. Many things affect uptime such as release and deploy cycles, maintainability, caching, scalability, configuration, and patching (no, not just security patching). Finally, maintainability affects ROI much more than security in the general case. Thus, security == level six.
• Developers cannot and won't prioritize security (or always dead last). Application security needs to be prioritized by the app owners and/or business/project owners. They are the ones who don't "get" development or security (and especially how they mix).
  
  A custom solution must be brought in and applied to solve the situational interests for almost every software project and production/published app. These solutions usually involve threat-modeling, code review, secure code construction, and app pen-testing -- where threat-modeling is the only optional component (sometimes issues are all too obvious, especially when responding to an appsec incident). Some appsec projects have other needs, but those are the basic 4.

1 more annotation...

• McGraw taxonomy has the following 7+1 classification:
   
  • Input Validation and Representation
   
  • Api Abuse
   
  • Security Features
   
  • Time and State
   
  • Errors
   
  • Code Quality
   
  • Encapsulation
   
  • environment
• The purpose is to build a root cause taxonomy for example the root cause of a security flaw according to CLASP can be classified depending the point of introduction into the SDLC in a hierarchical view.
   
  • Level 1: Identify Range and Type of Errors:Part of Level 1 you might have buffer overflows (introduced during Requirements, Design and Implementation), Command Injection (design and implementation), Double Free (implementation)
   
  • Sub level 2: Identify Environment Problems:Part of sub level 2 you might have resource exhaustion (design and implementation)
   
  • Sub level 3:Identify Synchronization and timing errors: TOCTOU, race conditions (design and implementation)
   
  • Sub level 4:Identify Protocol Errors:Misuse of cryptography (design)
   
  • Sub level 5:Identify Generic logic Errors:Performing a chroot without a chdir (implementation)
   
  The approach is effective in determining root causes of security flaws with emphasis on the when in the SDLC is actually might originate helping architects and developers to build security into the SDLC.

• Threat modeling is a process for modelling security threats and identify design flaws that can be exploited by these threats so that systems can be securely designed and countermeasures implemented to mitigate these threats.
• Requirements: Key stakeholders use white-boarding and collect information through worksheets to identify end to end deployment scenarios. The drawing of abuse cases allows the identification of negative scenarios and a preliminary threat analysis during requirement definition. Data classification can also be performed during requirements to drive the identification of potential threats to the data assets.
• Design:Threat modeling the system at design time allows system architects to validate and explore whether the design meets the level of acceptable risks. Flaws in the design can be exposed, and the information thus gathered used to improve the security quality of the design before the system is ever implemented. Furthermore, security testing efforts can be defined in terms of budgets and timelines.
• Operations:By threat modeling an application during system operations it is possible to identify and assess potential security risks and make informed decisions before change management events. Metrics and measurements can be gathered to plan the next releases. Lessons learnt can be used to develop best practices and standards.
• Threat modeling helps design architects to take a broader view on the security design of the system, hence, enabling them to be aware of a broad range of attack scenarios and threats. Furthermore, they can identify common mistakes made in designs, apply patterns and reuse principles. This leads to a secure design and therefore an improvement in the overall security posture of the system. Developers typically have detailed knowledge about the system's implementation and deployment and therefore their input is very important for threat modeling. When engaged in the process they can also learn how to avoid common implementation bugs and anti-patterns. This process also helps them to be focused on security and ensures it plays a critical role in their decision process.

3 more annotations...

• Firewalls need to be on every ingress/egress point in the organization or they don’t solve the problem. Firewall technology has to scale to be manageable over every connection and work on every size pipe. Network vulnerability scanners have to scale to scan every system in the enterprise. Patch management solutions need to scale to manage every system with any OS. Likewise the only way to solve application security is to scale it to every release of every app.
• we don’t just focus on the accuracy of our application security solution. We also focus on our solution working well at large enterprise scale. Our mission is to make it possible for an organization, no matter how large, to perform security testing on all apps: every release, from every source (in house, outsourced, vendor, open source), and on every platform
• Scaling application security is a hard problem that requires automation and humans. Manual effort cannot be eliminated so it needs to be made as efficient as possible. This can be done by offloading the parts of testing that can be automated to automated solutions. Let humans find authorization issues and machines find SQL injection. If humans don’t scale well then application security experts scale less well. We should design solutions where tasks that need humans can be performed by more available resources. Let QA people crawl through business logic constraints and feed that crawl into automation rather than drive tools with application security experts. These are some of the approaches we are taking as we learn how to drive application security testing through huge application portfolios
• I’m sick of educating users and developers and so should you be. I’m sick of preventative care when we’re flooded with new patients coming into the ER for a variety of reasons that have no conclusive root-cause. It’s not just SQL injection. It’s not just social engineering.

2 more annotations...

• One of the concepts that I think gets heavily overlooked in security is the idea of an assurance – the degree of protection a specific control provides. When speaking about assurance the discussion is how resilient a control is to attack; controls easily thwarted offer low assurance, controls very difficult to bypass offer high assurance
• Right now AppSec is very tactical. We are trying to fix the immediate problems through developer education and add on security frameworks, and as a stop gap that’s fine.
• For a strategy though, I think the various custodians of the languages/popular frameworks (MS, Oracle, SpringSource, the Apache Foundation, the PHP group, etc) should make a conscious decision to change the languages/frameworks to hide the default security decisions from developers in the exact same way that the move to managed languages hid buffer decisions. Add whitelist validation implicitly to the various parameter retrieval functionality based on the current character set, so that every time the developer accesses a parameter it is automatically sanitized (as an aside, I think languages should not automatically mix retrieval from Cookies/Get/Post variables). If the developer wants to deviate from the implicit input validation then have an unsafe version of the retrieval mechanism that they have to explicitly invoke (in the same way that you have to explicitly use the Unsafe keyword in C# for memory manipulation); that would still allow the current flexibility but it would make such a choice explicit for the developer and make flagging areas for manual code review very easy

1 more annotation...

• 1) Draw a data flow diagram (DFD) of how data moves around for your application/feature (depending on scope of the model), and where trust boundries are crossed

   

  2) Enumerate threats. The paper has a nice little matrix of what threats are pertinent to what elements of the DFD and while he applies the necessary conditionals about it being specific to MS and perhaps not being universally applicable, I think it is a pretty good reference in general.

   

  3) Determine Mitigations (or decide to let a threat slide)

   

  4) Validate mitigations that are put in place

   

  We lived by those simple steps, rather than getting into the horrid threat trees and DREAD risk modeling and all of that other overhead. I say this having been the security guy for my area in MS, supposedly the expert, and I ignored them. I can’t imagine the average non-security guy going to that trouble. Granted, being a security guy I probably find it a bit easier to subjectively (wait, am I supposed to say qualititavely now that I am a CISSP?) determine risk from a threat than put a number on it, which is what the overhead in threat modeling was supposed to do, but I think most non-experts can still make an educated guess.

• below breaks down my thoughts on the type of security testing that can be integrated into each role (developer, QA, Security)
• 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)
• that identifying a vulnerability through testing should ALWAYS result in the organization creating a new or correlating to an existing an 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

3 more annotations...

• 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.
• 1. Resource <- 2. Capability <- 3. Use Case <- User
   1. Resource <- 2. Capability <- 4. Threats <- Attacker
   
  1. Identify resources within the application, such as database tables, file systems, and application servers.
   
  2. 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.
   
  3. 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.
   
  4. 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.
   
  5. Assign a risk level to each threat, such as high, medium, and low.
   
  6. Define countermeasures based on the analysis of the risk level vs. the cost of implementing the solution
• 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.

1 more annotation...

• 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
• the six stages constitute an appropriate secure software development roadmap, instead; it simply describes a common progression observed in organizations
• 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.
• 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.
• 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
• 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

4 more annotations...

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

• 1) Be careful when using cross domain messaging features

  HTML 5 APIs allow to process messages from an origin that is different from the one of the application processing the message. You should check the origin of the domain of the message to validate that can be trusted such as by whitelisting the domain (accept only request from trusted domains and rejects the others). Specifically, when using HTML 5.0 APIs such as PostMessage(), check the dom-MessageEvent-origin attribute before accepting the request.
• 2) Always validate input and filter malicious input before using HTML 5.0 APIs.

  You should validate data input before you process any messages of HTML 5.0  APIs such as the PostMessage() API. Input validation should be done at a minimum, on the server side since client side validation can be potentially bypassed with a web proxy. . If you are using client side SQL such as WebSQL (like Google gears for example) you should filter data for any SQL injection attack vectors and use prepared SQL statements. 
• 3) Make sure that the use of any offline-local storage is secure

  Whenever possible, do not store any confidential or sensitive data in the offline-local storage, if you do, make sure you encrypt the data. If you do encrypt the data in the offline-local storage, do not store any encryption keys on the client rather, use the server to encrypt this data on demand. Make sure the encryption key is tied to the user's session and to the device that is storing it. Beware that HTML 5 offline applications are vulnerable to cache and cache poisoning hence validate the data before putting anything in offline/local storage. If should also consider to restrict the use of offline/local storage as requirement of your HTML 5.0 security coding standards is possible. Consider that right now (Jan 2011), offline-local storage is not supported by IE browsers, only by Google Chrome, Safari, Firefox and the beta of the Opera browsers.
• 5) Consider to restrict or ban the use of HTLM 5.0 websocket API.

  HTML 5.0 websocket API provide a network communication stack to the browser that can be used for backdoors. You should check with your security team whether the use of web sockets is allowed by your organization information security policies and application security standards.
• 
   

  6) Make sure your company legal approve any use of geolocation API.

  Consider the impact of privacy when using geolocation APIs to make sure the use is allowed and compliant by your company legal-privacy laws/regulations. The use of geolocation might have privacy impacts, hence should be reviewed to be in compliance with privacy policies that might include notify the user when these APIs are deployed as part of your application.
• 7) Leverage the security of sandboxing iFrame attributes

  One of the HTML 5  features is the sandboxing attribute for iFrame that enables a set of extra restrictions on any content hosted by the iFrame. When this is attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled and links are prevented from targeting other browsing contexts and plug-ins are disabled. Ian Hickson, the editor of the HTML 5 has a post on what the sandbox is good for. You should consider updating your organization's secure coding standards to cover how to code securely applications that leverage the HTML 5.0 sandbox attribute for IFrames.

4 more annotations...

• • Validate input. If you allow a user to post anything to your website, make sure that you only accept the input you want. Does the field ask for the person’s name? Then only text should be allowed. Need an email address? Make sure the @ symbol is present. In both cases, any code should be filtered out.
   
  • Escape untrusted data. Most websites don’t require data, however for those that do, escaping data the right way will still allow it to be rendered in the browser properly. Escaping just lets the interpreter know that the data is not intended to be executed. When the data does not execute, the attack doesn’t work.

• CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don't verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.

• That's the key element to understanding XSRF. Attackers are gambling that users have a validated login cookie for your website already stored in their browser. All they need to do is get that browser to make a request to your website on their behalf. If they can either: 

   

   
  1. Convince your users to click on a HTML page they've constructed 
  2. Insert arbitrary HTML in a target website that your users visit
• When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value.

1 more annotation...