Arnes Blanert wrote an extensive article for the architect magazine on the subject of Single Sign On (SSO). It covers both authentication and authorization via a variety of widely and not so widely used methods, including oAuth, SAML, JSON Web Token and more.
As someone who was involved in a variety of Single Sign On implementations (see some of the posts on the subject in my blog), I wish I had an article like this in my RSS feeds much much earlier.
“The Birth And Death Of Privacy: 3,000 Years of History Told Through 46 Images” is a rather extensive look at the history of privacy.
Privacy, as we understand it, is only about 150 years old. Humans do have an instinctual desire for privacy. However, for 3,000 years, cultures have nearly always prioritized convenience and wealth over privacy.
I said “there is no such thing as privacy, and there never was” way too many times. But I never had to go deep into the subject to defend it. This article, on the other hand, does a much better job defending the argument than I ever cared to.
BeEF is a browser exploitation framework.
BeEF is short for The Browser Exploitation Framework. It is a penetration testing tool that focuses on the web browser.
Amid growing concerns about web-borne attacks against clients, including mobile clients, BeEF allows the professional penetration tester to assess the actual security posture of a target environment by using client-side attack vectors. Unlike other security frameworks, BeEF looks past the hardened network perimeter and client system, and examines exploitability within the context of the one open door: the web browser. BeEF will hook one or more web browsers and use them as beachheads for launching directed command modules and further attacks against the system from within the browser context.
AWS Blog lets us know that Amazon has finally implemented one of the most useful features ever – descriptions on Security Groups rules. Previously, one could provide a description to the Security Group only, for example: “Proxy Server Access”. Which wasn’t very useful, as it was almost obvious. But now one can add a description to every rule inside the Security Group. So when you have a Security Group with a bunch of IP address ranges, you can now describe each one of them. For example: “HQ Office”, “UK Office”, “Boss At Home”, etc.
“The end of CSRF?” blog post talks about the new feature coming to browsers – SameSite cookie enforcement, which will help in getting rid of Cross-Site Request Forgery (CSRF) attacks. Too bad this is currently only supported by Google Chrome (both desktop and mobile), and Opera. But I’m sure it’s coming soon to the rest of the browsers.
Update: It looks like the above blog post is almost a copy of this blog post, which has a number of useful comments. Including this one, which links to a variety of projects and programming languages bug trackers requesting the support of the SameSite cookie feature. Also, it looks like SameSite cookie is superseded by the Cookie Prefix solution, proposed by Google.
Modern browsers offer a variety of security mechanisms for web developers. Unfortunately, some of these aren’t so easy to manage. One needs a deep understanding of the functionality as well as theory behind. Secure Headers is a library that makes all that work a lot easier for PHP developers. Here are some of the features:
- Add/remove and manage headers easily
- Build a Content Security Policy, or combine multiple together
- Content Security Policy analysis
- Easy integeration with arbitrary frameworks (take a look at the HttpAdapter)
- Protect incorrectly set cookies
- Strict mode
- Safe mode prevents accidental long-term self-DOS when using HSTS, or HPKP
- Receive warnings about missing, or misconfigured security headers
“Passwords Evolved: Authentication Guidance for the Modern Era” is a good collection of guidelines and concerns for password management in the modern day.
Here’s the bigger picture of what all this guidance from governments and tech companies alike is recognising: security is increasingly about a composition of controls which when combined, improve the overall security posture of a service. What you’ll see across this post is a collection of recommendations which all help contribute to a more robust solution by virtue of complimenting one and other. That may mean that individual recommendations such as dropping complexity requirements look odd, but when you consider the way humans tended to deal with that (they’d just choose bad passwords with a combination of character types) alongside guidance such as blocking previously breached passwords, things start to make a lot more sense.
Now there’s just one more thing: as good as all this guidance is, practically implementing it can be somewhat trickier.
“How to defend your website with ZIP bombs” has been making rounds on the Internet for the last few weeks. It’s both sad, that we have to resolve to such measures, and funny as to how tongue-in-cheek this approach is.
Whether you are going to implement it for your web host or not, it’s well worth reading, for a better understanding of what’s going on online, in places, that you are probably not looking at.
Brian Krebs has an interesting post on “Why so many top hackers hail from Russia“:
Conventional wisdom says one reason so many hackers seem to hail from Russia and parts of the former Soviet Union is that these countries have traditionally placed a much greater emphasis than educational institutions in the West on teaching information technology in middle and high schools, and yet they lack a Silicon Valley-like pipeline to help talented IT experts channel their skills into high-paying jobs. This post explores the first part of that assumption by examining a breadth of open-source data.
Overall, not very surprising, but the details and references are interesting. It seems a lot has changed since I graduated (back in 1995).
Via Slashdot, which also has some insightful comments.
- This document originated from a bunch of most commonly used links and learning resources I sent to every new web developer on our full-stack web development team.
- For each problem domain and each technology, I try my best to pick only one or a few links that are most important, typical, common or popular and not outdated, base on the clear trends, public data and empirical observation.
- Prefer fine-grained classifications and deep hierarchies over featureless descriptions and distractive comments.
- Ideally, each line is a unique category. The ” / “ symbol between the links means they are replaceable. The “, “symbol between the links means they are complementary.
- I wish this document could be closer to a kind of knowledge graph or skill tree than a list or a collection.
- It currently contains 2000+ links (projects, tools, plugins, services, articles, books, sites, etc.)
On one hand, this is one of the best single resources on the topic of web development that I’ve seen in a very long time. On the other hand, it re-confirms my belief in “there is no such thing as a full-stack web developer”. There’s just too many levels, and there’s too much depth to each level for a single individual to be an expert at. But you get bonus points for trying.