DevOps probably isn't killing developers.
But it is changing how people think about development - from running projects to a focus on building and running services. And more importantly, DevOps is killing maintenance, or sustaining engineering, or whatever managers want to call it. And that's something that we should all celebrate.
High-bandwidth collaboration and rapid response to change in Agile put a bullet in the head of offshore development done by outsourced CMMI Level 5 certified development factories. DevOps, by extending collaboration between development teams and operations teams and by increasing the velocity of delivery to production (up to hundreds or even thousands of times per day), and by using real feedback from production to drive development priorities and design
Security researchers discovered and disclosed the Clickjacking attack (also known as a "UI Redress Attack") back in 2008. All major browsers were affected. Flash even had an interesting vulnerability that allowed control of a user's microphone and webcam. Yet, here we are 7 years later still citing this issue on nearly every security assessment of web applications that we do. During our report delivery, development teams typically have one of the following responses: "What's Clickjacking?", "What can someone really do with this?", or "So what?".
I'd like to take a minute to explain a little bit about this exploit, give a quick example, and talk about a few ways to mitigate this issue.
Clickjacking involves hosting a form from the application in an iframe and tricking the user into activating the form. A common way to do this is to set the opacity of the iframe to 0 (rendering it invisible) and placing a link over a button on the
Continuously ranked in the OWASP Top Ten, a large majority of the development community still doesn't understand Cross-Site Request Forgery (CSRF). After years of penetration tests and code reviews, my experiences show that a high percentage of applications, especially new applications, do not have proper CSRF protections in place. This post provides a refresher on CSRF and provides a common defense for this issue.
CSRF occurs when an application trusts that all requests originating from the user's browser are user-directed actions. Imagine that you are logged into your bank's online portal. The application requires users to authenticate and passes a session cookie back to the browser. Subsequent requests made to the banking site must contain the session cookie, allowing the site to identify the user and perform the requested action.
What if an attacker could send a fake request using the victim's browser?
Suppose an attacker wants to
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