Do you ever get the feeling that something’s not quite right after you’ve performed an otherwise solid web security assessment? Well, as many of us have discovered, that nagging feeling in the pit of your stomach could be something as simple as not disabling the web security testing accounts you’ve used during your assessment. If a web application has been properly reviewed, these web security testing accounts will have been put through the wringer. Some may be locked out while others may have weak passwords or no password at all.
I can only imagine how many accounts created especially for web security tests are available for manipulation on the web at this very moment. You simply can’t afford to have these accounts – regardless of their privilege levels – sitting around waiting to be exploited by some criminal with nothing better to do.
In the majority of situations I’ve seen these web applications are in production so there’s a lot to lose. If you’re lucky, you’ll end up being able to test a development or staging environment. These systems aren’t supposed to house production data, so you can just leave those web security testing accounts hanging in the balance, right? Ha – maybe on paper but there’s application logic, potential source code and almost always some form of sensitive information on “test” systems that are all ripe for the taking. Much to the chagrin of IT auditors, compliance managers and big government regulators, it’s how the world works. Either way you look at it, unsecured accounts on any web system can create big business problems.
Further complicating matters, there’s often a large team of people involved in the web security testing of any given web application. Any given project can have a project manager, developers, internal IT staff, information security staff, third-party IT service providers and cloud providers with their hands in the security assessment pie. Quite often there’s no clear leadership on application development and website security – related projects and everyone just sits around waiting for someone else to make a decision. As Murphy’s Law suggests “If more than one person is responsible for a miscalculation no one will be at fault.” This can leave us security professionals in a bad position.
Be careful here. You don’t want the perfect storm to come about that ends up leading to a web application vulnerability that you helped facilitate. If it’s clear to you that no one is in charge, take it upon yourself and do what you can to ensure your web security testing accounts are disabled/removed and everything’s properly buttoned up before moving forward. Even if it’s ultimately someone else’s responsibility, it’s up to us to make sure things aren’t left undone.
To keep up to date with the latest security news ‘Like’ the Acunetix Facebook Page, read the Acunetix Security Blog and follow us on Twitter.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
