A friend of mine recently unveiled a new version of his website. Given that I too had worked on it sometime back, I decided to check it out. The main points I looked out for was security holes, since there were numerous such flaws which I fixed years ago. Rather unsurprisingly the password reset feature of the site had one such ‘vulnerability’. It was done anew and the method used was not the most recommended although many developers opt for it. It wasn’t a bug, but a bad implementation ready to be exploited.
The culprit was an incorrect use of base64 encoding. For me, the main uses of base64 are storage and transmission of non-secret data. Although in the case of storage it’s something like hashing binary data etc. The last part ‘non-secret’ is very important. Because if one was to use the same for ‘secret’ information, then again it’s a non-recommended use. In the above scenario that was the exact thing that happened. A piece of data which was meant to be secret and easily non-readable was sent publicly after encoding with base64. And as most developers know, it’s just a jiffy to decode base64. So what I did was decode the string value, only to find out that two values were concatenated. One value was the victim’s email and the other a randomly generated string which wasn’t that hard to identify. Then it was merely to modify the above value with a known user’s email. And voila! I could reset his/her password.
Mentioned above was how a badly implemented encoding could make your web application vulnerable. And this is not something associated with low-profile companies, but even Facebook had a similar situation which was revealed in this article at 'Hacker News'.
The remedies are many, depending on how far you’d be content with given that security isn’t a 100% achievable thing. One solution is to make the random ‘salt’ a highly cryptic value. Another is to use a well-recognized encryption mechanism. Or you could even develop your own encrypt function although security experts warn against this. A rather straightforward and often used method is to implement one-way hashing such as MD5. All this methods have their advantages and perils. It’s up to the developer to decide which is best depending on factors such as performance, importance, accessibility, etc.
The culprit was an incorrect use of base64 encoding. For me, the main uses of base64 are storage and transmission of non-secret data. Although in the case of storage it’s something like hashing binary data etc. The last part ‘non-secret’ is very important. Because if one was to use the same for ‘secret’ information, then again it’s a non-recommended use. In the above scenario that was the exact thing that happened. A piece of data which was meant to be secret and easily non-readable was sent publicly after encoding with base64. And as most developers know, it’s just a jiffy to decode base64. So what I did was decode the string value, only to find out that two values were concatenated. One value was the victim’s email and the other a randomly generated string which wasn’t that hard to identify. Then it was merely to modify the above value with a known user’s email. And voila! I could reset his/her password.
Mentioned above was how a badly implemented encoding could make your web application vulnerable. And this is not something associated with low-profile companies, but even Facebook had a similar situation which was revealed in this article at 'Hacker News'.
The remedies are many, depending on how far you’d be content with given that security isn’t a 100% achievable thing. One solution is to make the random ‘salt’ a highly cryptic value. Another is to use a well-recognized encryption mechanism. Or you could even develop your own encrypt function although security experts warn against this. A rather straightforward and often used method is to implement one-way hashing such as MD5. All this methods have their advantages and perils. It’s up to the developer to decide which is best depending on factors such as performance, importance, accessibility, etc.
