A web development team in my company that was deploying a newly developed website faced the annoying security warning issue. When any page was accessed over a secure layer the browser would cause a security warning –
“This page contains both secure and nonsecure items”
When they asked me to help out, I sat down with the developer and found out where they were so far in analyzing the issue. He had his own suspicion on a menu (that they recently used downloading it free from some website) and was hitting hard on reading through the script.
Of course there was a complete possibility of the script causing the issue, we just cannot rule out the rest of the website as totally safe. So we started with a simple .htm page which caused the security warning to pop up.
First step – we saw the html source if it contained any direct http:// links. There were a couple which we promptly removed.
Secondly – we looked for any JavaScript “document.write” writing any http:// link. We also checked the CSS styles for any image URL reference or any such. – Things looked clean
Third step – enter fiddler. Trace the requests and the response. There was this one setting in the Advanced tab we had to enable for tracing the https requests and responses.
Now we found that the warning arose at the point of loading the suspicious menu.js but that was not the problem, there was a problem a few entries before – a 404 error for some stylesheet file. Apparently there was a link made to a style sheet which was moved to a different location.
Next step – fixed that error and redeployed and ran the trace again. This time the trace stopped at a different location. But yet again there was another 404 error. This one was strange since it just says the file was https://www.website.com/home/white
The actual problem was the page had defined the background attribute of the body element as white. Like this:
<body background="'white'">
What should have been bgcolor or could have been done with styles. White was interpreted as a file and the browser was expecting one.
We fixed that one too and it is now resent for yet another re-deploy. One lesson learnt is to always have a SSL enabled QA environment to test for such SSL specific issues – which could have saved loads of time.
No comments:
Post a Comment