Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: "Insecure" technical requirements for online course? - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
"Insecure" technical requirements for online course?
These are the ones from the above page that I find the craziest:

--Cookies enabled
--JavaScript enabled
--Flash enabled

And here are some entries in the "These sites need to be whitelisted" section:

INTEGRATIONS - Requires all subdomains and folders:
*.ramseysolutions.net/*
*.cloudfront.net/*
*.akamai.net/*
*.typekit.net/*
*.adobedtm.com/*
*.newrelic.com/*
*.jwpltx.com/*

Here's the reason they give for the above list:

"A note on integrations: For the best experience with SmartDollar, our recommendation is to allow traffic as we’ve prescribed above. If this is in conflict with any of your specific network policies, your IT staff should be able to help identify solutions that meet the needs of your policies. We are not able to provide all or exact URLs for each integration as these could be dynamically updated or changed by either SmartDollar or the party we are integrating with at any time to optimize, improve, or expand our product offering."

But maybe I'm being too lazy or curmudgeony? I suppose a properly designed network that is truly secure wouldn't have any problems with these requirements, yes? But doesn't putting something like "*.akamai.net/*" in a firewall whitelist open up a big hole for bad things to come through?

Best regards,

Mark
Marko

7 Posts
Well, that is indeed a dangerous list.

I think "Cookies, JavaScript" enabled are perfectly appropriate requirements for deploying a Web-based application.

The whitelisting of EVERYTHING on numerous 3rd party CDNs is not reasonable. It sounds like a "Proactive whitelisting approach" strongly favoring convenience for the developers and application
vendors over customer maintaining their company security posture.

Since such excessively broad whitelisting kind of makes the security solution useless; my suggestion would be that some of the requests for whitelisting be denied.

If the company's firewall is so unreliable, that routine whitelisting is required for common applications, then replace the firewall with a better solution!


The real issue is there's no way to create a whitelist entry that says "Whitelist *.cloudfront.net, But only when the resources called from CloudFront are being requested by Windows Program X in reference to http://trustedsite.example.com"

Perhaps security software running in the browser itself could determine this, or a "Special browser instance" could be launched using a special proxy for connecting JUST to that vendor's website, but firewall solutions cannot automatically know the context of a request to X.cloudfront.net to decide the difference between a HTTP request from the trusted App, and unrelated HTTP traffic, possibly a malware link or malicious JPEG from an ad that happens to be hosted on cloudfront.
Mysid

146 Posts

Sign Up for Free or Log In to start participating in the conversation!