AngularJS 1.6 was recently released. With this release comes several impactful changes. One such change to note is the removal of the expression sandbox. This was a predicted change that was first announced in early September. If you haven’t already evaluated the impact of this on your Angular code in preparation for the changes, it’s high time to do so.
Is your code mature enough to survive life outside the sandbox?
The answer is so simple that it might surprise you–life outside the sandbox is no different than life inside. It should have no impact on the security of your AngularJS application. You see, Angular expressions weren’t sandboxed for security reasons in the first place. It was not intended to act as a security boundary. Therefore, the various ‘sandbox escapes‘ published by security researchers were never considered to be vulnerabilities. Even so, the Angular team continued patching the sandbox until the recent release of 1.6.
Posted in Application Security
Security, including software security, is very much rooted in a control culture. Security concepts such as firewall rules, access controls, and input validation are all about getting and keeping control—we frequently refer to these as security controls. Standardized processes that promote stability and order are also highly valued components of security. This control culture often causes friction when security is introduced in agile development teams that have a very different culture.
Working with the culture, not against it
Agile software development is more about culture than a set of processes, although it is often mistaken for the processes it is associated with (e.g., scrum). The values and beliefs that define the idea of agile are described in the Agile Manifesto. This manifesto does not define a specific development process, but rather the values and priorities that underpin agile software development.
Posted in Agile, CI/CD & DevOps, Software Architecture & Design
I recently discovered an important security issue in Socket.IO—a zero-day vulnerability that allows a man-in-the-middle attack on TLS-protected communication between a Socket.IO client and a Socket.IO server. I find this issue rather interesting because it shows how unfortunate design decisions can unintentionally lead to insecure default configuration. This also highlights the dangers of not following secure design principles.
Posted in Open Source Security, Software Architecture & Design