1. Don't Break Your Backbone: XSS mitigation in Backbone.JS

    Cross-Site Scripting (XSS) has maintained its status as one of the most common application security vulnerabilities since the infancy of the internet. There are three types of XSS, and each type can occur in multiple contexts. In addition, numerous modern front-end frameworks and libraries each offer their own custom solutions. Naturally, proper XSS mitigation poses a unique, application-specific set of challenges. We recently discovered a common library-specific issue during a recent assessment of an application that used Backbone.js.

    Backbone.js ("Backbone") is one of the most popular JavaScript libraries for front-end application development. It features models for data key values, collections for working with sets of models, and views with event handling. Backbone has become ubiquitous, with companies  like Airbnb, Groupon, Pandora, and more implementing it for their web applications. Backbone is a flexible library to help glue together front-end data management and the display of data. As JavaScript libraries and frameworks push more and more app functionality to the browser, they push more risk and responsibility there as well. JavaScript frameworks can (and do) introduce many of the vulnerabilities we see in back-end applications.

    We can't show client code in this post, so we'll use a sample Backbone app, backbone-jax-cellar. This is an open source project to demo Backbone with a Java back end.

  2. A Survey of Google Trusted Stores

    Google Trusted Store is an endorsement placed on qualified e-stores that allows consumers to "Shop online with confidence." Through various metrics, including the number of daily consumers as well as shipping speed and reliability, Google determines whether or not an applicant is deserving of the endorsement. The entire application process generally takes between one to three months. Stores that receive the endorsement are able to display the Google Trusted Store badge on their website.

    Original image from Google

    Previously, Google would only allow the badge to be displayed on pages that were served over non-secure connections. Confused by this decision, I emailed the Trusted Store team asking for confirmation. Here is their response:

    Actually, we currently suppress the badge from displaying on HTTPS pages. So if the entire site is on HTTPS then we won't be able to display the badge…
    To clarify, if a site is entirely is in HTTPS, then currently we do not support that scenario and the merchant cannot be considered for the Trusted Stores program.
    This policy has since changed, but the initial rule resulted in some lingering security issues on many Google Trusted Stores. Google now has increased requirements surrounding stores' SSL implementations:

    Payment and transaction processing, as well as collection of any sensitive and financial personal information from the user, must be conducted over a secure processing server (SSL-protected, with a valid SSL certificate - https://). Merchants remain responsible for ensuring that they are compliant with local laws and regulations on the subject of privacy and data protection. Google may suspend any account found to be in violation of our policy or the law.
    In this blog post, I'll summarize the prevalence of passive security vulnerabilities across 25 arbitrarily chosen Google Trusted Stores. These vulnerabilities were found via passive analysis of the web applications through usage as a normal user, not a penetration tester. No malicious payloads (such as SQL Injection or directory traversal) were delivered to any of the servers.

  3. You. Yes you. Read this!

    When I was in the Navy, we learned seemingly simple things like "Don't wear jewelry on a ship," "Keep your hands out of the hatches exposed to the outside of the ship," and "Don't wear contacts when a chemical attack has been detected." We also spent more time on the safety behind using a weapon than the actual act of firing a weapon. In fact, we repeated our safety training before all major weapon qualification exercises. Why? Because jewelry can lead to serious issues around magnets or high-powered ship equipment, hands in a hatch on a windy day can lead to (I've seen this) a loss of fingers, contacts can become seared to your eyes during a chemical attack, and well, people do unpredictable things in an adrenalized state while holding a weapon.

    Now, clearly, a loss of life or limb is not necessarily the outcome of a successful application attack; but the fundamentals, the mundane rules we security folks give you during training, can save you, your organization, and its users from easily preventable problems that could be pretty damaging.

    Why do I bring this up?

  4. Method Interchange: The Forgotten Vulnerability

    When you think of the most prolific scorers in NBA history, you think of names like Kareem Abdul-Jabbar, Bill Russell, and Karl Malone. Most casual basketball fans aren't familiar with names like Oscar Robertson, Bob Cousy, or John Stockton, but without these men, the previously mentioned scorers would have been much less effective as an offensive threat. And thus is the life of the Method Interchange vulnerability.

    I've mentioned Method Interchange in several application security circles recently and have been greeted with strange looks and questions of "Method what?" Once I explained Method Interchange, the reaction changed from "Huh?" to "Oh my, I need to check for that from now on!" Quite simply, Method Interchange is the ability to send parameters via the URI query string or request payload and have them processed by the application, regardless of which was originally intended. While seemingly benign, Method Interchange drastically increases the exploitability of other, more capable attacks.

  5. Node.js: Put a Helmet on...

    With Node.js being all the buzz these days, I figured it was time to take a break from our normally scheduled Burp series and do a small sidebar on Helmet for Node.js. I've been working heavily in Node applications recently and realized just how common some of these "easy-fix" vulnerabilities are becoming.

    Node is an interesting beast with a budding community that is anxious to get a good handle on security; luckily, tools like Helmet provide a set of controls that can really help with that. Helmet was mentioned in Mike's last post on Javascript security tools, and if you're running a Node application, you can get some of the low-hanging fruit in the bag quickly and easily.

  6. Scala-Flavored Assortment of Play Injection Prevention Techniques, Part I: SQL

    Although many database access libraries are touted as injection-proof or secure by default, there are often plenty of exceptions in the fine print. Using the libraries in the "intended" way may magically remove the risk of injection attacks (unless there are flaws in the libraries themselves), but if you deviate from that way, you're on your own. Often, developers revert back to plain old SQL simply because they can't get their ORM to play nicely. Or, their generated code ends up being significantly slower and less efficient than churning out the SQL by hand. Or, they build apps with NoSQL databases and assume that NoSQL = No Problem.

    In this three-part series, we'll walk through the secure way to implement a few popular libraries for accessing databases and caches within Scala web applications. We'll focus on libraries commonly used in Play web applications targeting SQL databases, MongoDB, Redis, Apache Hive, and Apache Cassandra.

    If you've never heard of Injection or one of its most notorious variants (SQL Injection) before, start here first: https://www.owasp.org/index.php/SQL_Injection.