Steve Kosten is an instructor with the SANS Institute for DEV541: Secure Coding in Java/JEE.
Password Storage Mistakes
I was visiting a web site recently that I haven't visited in many, many years. I tried a few old passwords I used to use before I started using a password storage system, but no luck. I was defeated. Barred from entry into this site. But wait, they have a "Forgot Password" link; knowing I will soon have entry into the site, I confidently click on that link (after entering what I believe my username is). Boom, a few seconds later, I have an email from this web site that I will not name. Opening the email, there it was. The password I had created from ages ago. Head-slap.
The head slap wasn't for me forgetting my password; what were the developers of this site doing storing MY PASSWORD in clear text??!! Where anyone with
Greg Leonard is an instructor with the SANS Institute for DEV541: Secure Coding in Java/JEE.
REST Security Protections
Representational State Transfer (REST) has become popular in modern web application development. They take advantage of HTTP, a well established web communication protocol, and provide a simple-to-understand framework for delivering a flexible and highly performant content delivery method for web services (known as RESTful services). However, adoption of REST has seen some resistance as it does not include any standards for security. This means that every service developed that wants to provide authentication, authorization, validation, encoding, or any other security concern is essentially on their own. Clients that want to consume these services are likewise responsible for creating custom interfaces for every REST service
If you didn't know already, Google takes its application security seriously, especially when it comes to Cross-Site Scripting. They already have a Vulnerability Rewards Program and XSS Learning Documentation posted on their application security site. A few weeks ago, I saw some chatter on Twitter about a new approach for teaching folks about Cross-Site Scripting: The XSS Game! Wait a second, teach people about XSS by playing a game? It sounds like an app I would download on my tablet for my daughter to play with. Brilliant! Where do I sign up?
During a recent mobile security engagement, I discovered an Insecure Redirect vulnerability in the LinkedIn OAuth 1.0 implementation that could allow an attacker to conduct phishing attacks against LinkedIn members. This vulnerability could be used to compromise LinkedIn user accounts, and gather sensitive information from those accounts (e.g. personal information and credit card numbers). The following describes this security vulnerability in detail and how I discovered it.
Section 4.7 of the OAuth 1.0 specification (RFC 5849) warns of possible phishing attacks, depending on the implementation. A vulnerable OAuth implementation could enable phishing attacks via user-agent redirection. The stated emphasis, further supported by OAuth 2.0 (RFC 6749 via "redirect_uri" parameter), is intended to raise awareness of open-redirection as a security vulnerability that should be avoided.
For the second year in a row Jim Bird and I have helped SANS put together a "Survey on Application Security Programs and Practices". We asked some of the same questions as the previous year, just in a different way. Some interesting trends this year, as taken from the executive summary of the soon to be published paper, include the following:
- There was a significant improvement in the number of organizations implementing application security programs and practices. The percentage of organizations that have an active Appsec program increased from 66% last year to 83% this yearand many of the organizations that do not have a program in place yet are at least following some kind of ad hoc security practices.
- Organizations are testing more frequently. In this year's survey, more than one-third are doing continuous, ongoing security testing of their applications, whereas only 23% indicated doing so in our ...