So another year passed by and I will talk ( again , ... ) at the Connect WE conference . This year with Damien Antipa we will have a speech entitled So, you wanna crypto (in AEM) . Now, is true that even symmetric encryption isn't a “solved problem” but hey we still need to protect information et al :) Now is probably well known that messing up with cryptography isn't that hard :p Luckily Adobe Experience Manager (AEM) offers a great suite of cryptography capabilities as : Encryption and decryption API Integrity protection API Key pair generation TrustStore/KeyStore support In this talk we will show how to use those low level building crypto building blocks to solve scalability and resilience problems i.e. improving the efficiency of load balancing with horizontal scalability and providing a transparent stateless CSRF framework .
Posts
tl;dr The Internet Bug Bounty rewarded me with a bounty for an Open Redirect in rfc6749 aka 'The OAuth 2.0 Authorization Framework' . Here the long version. The Introduction Several months ago I did realize that if you want to implement an OAuth Authorization Server and follow verbatim the OAuth core spec you might end up having an Open Redirect. Now there is still some debate about this class of vulnerability since often they are relatively benign but not always (as we can see later). Despite all at that point I notified the OAuth working group . There was some longish discussion but eventually (almost) all in the list agreed that this was somehow an issue (no where near the end of the world :)). The Issue Section 4.1.2.1 of the OAuth specification says: If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHO...
Here I posted the slides of the JUG event in Basel . I have been kind of quiet lately in this space. I have a couple on vulnerabilities outstanding (one OAuth related and one browser related). Waiting for the green light... stay tuned
Heya, back to my favourite topics namely OAuth . I have previously discussed about common OAuth 2 Implementation Vulnerabilities but now it is time (maybe) to list those and order them based on their criticality. #5 The Postman Always Rings Twice I have introduced this 'attack' in last year post . This is for provider implementer , it is not extremely severe but, hey, is better to follow the spec. Specifically The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. It turned out that even Facebook and Google did it wrong ... :) #4 Match Point To all OAuth Providers be sure to follow section 4.1.3 of the spec in particular ...if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if...
As usually I always try to blog about my "security finding" . The main reasons are basically two: I think is really good to share knowledge in this area. Sometimes I do use my blog posts as a place to store information that I can always access in the future. Unluckily though I am a really lazy blogger and sometimes I just do not blog :S The really good news is that the last vulnerability I found is in github . I already blogged about how good and responsive is the Github security team. And I am now even more impressed by their efficency. The reason why this is a really good news is that in this case I can do both : 1) find a vulnerability 2) being lazy and not trying to describe the vulnerability I found, this because the github team is already describing the vulnerability in their wall of fame :) Hurray.
Usually my (not too many :( ) posts are written for a technical audience (not t o o big :( ). This time, given the fact October is Cyber Security Month I will try to put some effort to try to explain how you can keep yourself away from annoyances. Well the rule of thumb is actually extremely simple and can be resumed with a simple sentence: Beware what you click Let me repeate it: "beware what you click" :) Just following this simple rule you can avoid 90% of scam/viruses and phishing attacks . But lets do a step back. Assuming you know already what is a computer's virus let me explain what is a phishing attack. Phishing scam uses legitimate-looking websites to trick a victim into sharing their username, password or other sensitive information. Pishers will design their sites to look exactly like e.g. the website of your mail provider, your bank, credit card issuer, or another financial institution. The hope is that you won't realize you...
In my previous blog post I mentioned a following post about some vulnerability I found in https://accounts.google.com/. As said, motivated from my little success that I got finding a vulnerability in some obsolete authorization service in Facebook I thought I might have the same luck with Google :) Well it turned out this was the case... Giving a look at the Older Protocols in the Google Accounts Authentication and Authorization page something that immediately caught my attention was the AuthSub (deprecated) flow. Now, I am not going to describe here the flow, it is enough saying that it is a pre-OAuth flow that Google used to give some access delegation using some sort of tokens... The problem was related with the scope parameter in www. google .com/accounts/ AuthSubRequest . It accepted concatenation of string after a valid scope. E.g. https://accounts.google.com/AuthSubRequest?next=https%3A%2F%2Ffd.xuwubk.eu.org%3A443%2Fhttp%2Flocalhost%3A8080%2Fa&scope=https%3A%2F%2Ffd.xuwubk.eu.org%3A443%2Fhttp%2Fwww.google.com%2...