Some Web Domain Security Tips
I was informed by Mike Jolley that my name appears in print in issue 169(?) of .Net Magazine — which apparently goes by the name of “Practical Web Design” in the United States but I wasn’t able to confirm this, even with Google’s help. When Mike told me this and kindly furnished me with a scanned copy I recalled being interviewed some time back. Others interviewed for this article were Dave Barter for Legatio.com and Marcus Graichen for MogMachine.com. .Net spelled my name wrong and didn’t publish my domain properly (no hyphen), but the info was hopefully sound all the same.
I have posted the article as two images — the main article and a sidebar — which I will not fully transcribe (I’m too lazy/busy), but here’s what I wrote:
Main Article
The name of this article (a regular section perhaps) was “Expert Tips” — hmm, that’s flattering.
Never open your domain’s file structure to the public. Keep it locked down. If you don’t know how, learn. Experimentation is unforgiv[able] in this case. Files with public access permissions are vulnerable, but they don’t have to be. Ownership can be passed to the application that requires access, at which point access can be removed to all other parties.
— I said it
Always verify and filter user input. Always. Forms, search… it doesn’t matter. Filter it all.
— Me again
A lot of information can be gleaned from monitoring your domain’s logs: error logs, referrers, and accessed files. All of these can reveal security exploits that are being implemented. It’s a good idea to look at your physical file structure to look for anomalies such as files you don’t recognize and files that show updated dates later than when you last updated them.
— Yep, that’s me too
Learn to validate your domain to include accessibility evaluation. If you have a quality site and suddenly find errors and problems, it could be because something was added to your pages to you didn’t put there yourself. Miscreants are notoriously sloppy and not web standards-minded, and this can lead to exposure of their handiwork.
— Again, I said it
Sidebar
The title of the sidebar was “I wish I’d known that (when I was a rookie developer)” and what follows is my contribution.
Every day, exploit attempts are made on my seven domains. I’ve learned that checking error logs will reveal these exploit failures. It won’t bring a smile to your face, but it beats being oblivious.
— You guessed it, me again
That’s it. Hopefully the others interviewed will post their tips so non-subscribers can get them all. The advice is basic and obvious to some, but the view from my rocky outcropping tells me it’s basic information like this that’s desperately needed by many.
Marcus Graichen responds:
Posted: November 14th, 2007 at 3:56 pm →
It would seem i was as flattered, ..and apparently slightly more lazy (i think that is a developers word for BUSY) than you, as i haven’t even got around to scanning them yet, ..so just a thank you for saving me the trouble.
-mog
Cole responds:
Posted: November 14th, 2007 at 7:39 pm →
did get a bit confused when they advertised the wide words of a certain mike cherin (any relation?) but another good issue from the guys (and gals) at .net mag
Cole responds:
Posted: November 14th, 2007 at 7:40 pm →
er, that should be have been wise words
Jermayn Parker responds:
Posted: November 14th, 2007 at 9:04 pm →
Who has GreenBeast.com??? They may get some unexpected traffic
Mike Cherim responds:
Posted: November 14th, 2007 at 9:16 pm →
It’s not ne that’s for sure
I checked it out and it’s for sale for $2670.
JackP responds:
Posted: November 15th, 2007 at 6:29 am →
Well, if we ignore the spooling errors, it was a nice article, and I too enjoyed the wide words of everyone concerned.
As a developer in a large organisation, security becomes compartmentalised: I’m not worried about or responsible for server configurations, firewalls and the like, but I am responsible for my applications:- and for the most part this seems to break down as protecting against XSS and SQL injection attacks.
It’s worth remembering that security needs to be broken down (and considered) in different layers, from the OS and comms used all the way through to application-level security. These don’t necessarily need to be the responsibility of the same people in larger organisations (e.g. it makes sense for development teams to look after application security) but it is also worthwhile having someone with an overall view of the organisation’s security.
Finally, I’d like to re-emphasise what has already has been said: never trust user input. I’d clarify this further: never trust user input even if you verified it on a previous screen: a hacker could have bypassed that previous screen by creating their own customised version of your previous screen to bypass that validation.
Anthony Brewitt responds:
Posted: November 23rd, 2007 at 4:16 pm →
Mike J told me about this - I’m going to get the back order its always cool to see peeps getting recognition and believe me this is the best selling design mag In the UK! WELL DONE!