Through Obscurity?

Sep 3rd, 2014

Comments: 0
Category: Software Security

Through Obscurity?

An on-going theme I see on Security sites is the controversy around ‘Security through Obscurity’ which is generally felt to be a bad thing. So the justification of this tends to be something along the lines of ‘Don’t think that because you’ve not put a great big link to /supersecretfunctionality on the front page of your web site that some hacker isn’t going to find it’. This is correct and reasonable as far as it goes, though I personally think that some people take it too far and advertising a Web Server as running ‘Apache xx Mod xx Open SSL xx PHP xxx’ is just asking for trouble unless what you are doing is rigorously keeping up to date and advertising that fact.

Having said all that, I think there is a point at which ‘obscurity’ security measures can in and of themselves become a good thing – regardless of whether they were deliberately designed as such. I came across a good example this week while doing some development work on a Web Service.

As some people will know ‘old style’ web services tended to rely on a WSDL (basically a descriptor of the message format a request would have to be in to be accepted and processed by the service). Quite a lot of the ones we test are old ASP.NET based ones and by a (bad) default expose their WSDL (so if you make a request to mywebservice.asmx you get a detailed description of the service endpoints and the parameters they accept). Unless what you are doing is writing an API for public consumption this is obviously a bad plan, and you can suppress this by adding the following lines to your IIS machine.config.



So once you have done this – the WSDL for your service is no longer exposed, and my point would be that what you now have is a solution which is inherently more secure than a REST based service that by its nature exposes its structure to public view. This is simply because an attacker is going to have to do a lot of work to discover a valid message format, whereas with the REST based one it is really easy to work one out – just because it is so logical and simple.

Having said this I have had major arguments with other security professionals who disagree with this approach and believe that the more modern REST style architecture encourages developers to get their authorization management correct by exposing the URLs and making any flaws easy to discover and presumably correct.

Add a comment

Your email address will not be shared or published. Required fields are marked *