There is a rule used in motorcycle racing: before blaming your bike for a slow lap, look at the rear view mirror and you’ll find the cause. Or, maybe better, the first enemy for your security is yourself.
I was checking code to find eventual broken authentication issues on a website and i found the way to build a public link and get as result the web.config of the application… yes, with all the passwords.
Now, DO NOT PUT YOUR PASSWORD IN A .CONFIG, but this is another story: the problem was that one page [first tier] used a service [in the second tier] to access the filesystem and get the last uploaded file… and the file name was passed in POST (https… ahahahahaah)!
The application in general was kind of secure, but this page opened the entire system to every kind of attack… and we don’t know what our coders are putting inside the pages and we know that the testers will never spot this error.
The ONLY security check on this page was this:
If Not Session("COMPANY") Is Nothing
…and the website created the default Session(“COMPANY”) in the Session_Start.
So, not only the only check present was not useful at all, but there was NO CONTROL of which file was passed, if the request was Authenticated and IF THE FILE WAS VISIBLE to the authenticated user. This is the main point: when you display/modify data ALWAYS, ALWAYS, ALWAYS force a check which controls the relationship between the user and the content. And never forget to do it in the service tiers as well… a shared security header can save your system also from the most lost developer.
IF you didn’t do it yet, run a scan on “Request” parameters (.QueryString, .Params, .Form), you’ll have some strange surprises…
Just advice for today, tomorrow we talk about performances and code builders… especially for Database!
Ah, I forgot in the other posts… Comments or idea for better implementations are always welcome!