Hey all, so we had a security scan run on our code and we got this issue: Web Server Misconfiguration: Unprotected Directory...directory is called Scripts....we are on AWS and Windows....any thoughts on what to do to solve this issue? webaddress/scripts/xxx.js

Is it allowing directory browsing (showing the files) if going to that directory?

if I go to the full file path https:://xx/scripts/filename.js, the code from the file shows in the browser...if i try to see just the scripts folder, it won't show the dir list

Sounds like a false positive “error”

hmm, interesting...and a Cors policy...i'll have to review what that means, but yeah, the site needs to get into that folder to read js files....

Basically a cors policy prevents the scripts from being accessed by other domains or limits it directly to the ones you specify being allowed to use it

Thanks Patrick...i'll pass this on to my coworkers and we can use this to figure out what to do....

Yeah, "unprotected" seems a little over-stated. It's a freaking JS file-- of course the server should service it up, lol

hey, brad, so you think I should look more into Cors policies we have, like Patrick mentioned, or do you also agree this might be a false positive?

I wouldn't only look into CORs if the security scan specifically says that's what they want

ok, i'll have to see if it does...think Patrick just brought that up as a possibility\

Web Server Misconfiguration: Unprotected Directory

could mean a lot of things so you're wasting your time going down any rabbit trails until you get clarification

Yea and what scanning tool this comes from

A google of that exact phrase, returns a lot of hits for a tool called "Webinspect"

i am going to post the whole description of what this tool says we should do to the error, however, you just mentioned a js file returns a 200 we have a HTTP/1.1 200 OK so maybe that is what you are reading about

Is the file in question some sort of well known path for files which should not be publicly accessible?

here is the explanation: Web Server Misconfiguration: Unprotected Directory Explanation A directory was discovered that contains an object referenced in a post request or query string, and which has a name that could easily be guessed by an attacker. The primary danger from an attacker discovering this directory would arise from the information he could gather from its contents, such as what language was used to code the web application. Recommendations include restricting access to important directories or files by adopting a "need to know" requirement for both the document and server root, and turning off features such as Automatic Directory Listings that provide information that could be utilized by an attacker when formulating or conducting an attack. Summary: A directory was discovered that contains an object referenced in a post request or query string, and which has a name that could easily be guessed by an attacker. The primary danger from an attacker discovering this directory would arise from the information he could gather from its contents, such as what language was used to code the web application. Recommendations include restricting access to important directories or files by adopting a "need to know" requirement for both the document and server root, and turning off features such as Automatic Directory Listings that provide information that could be utilized by an attacker when formulating or conducting an attack. Execution: This check determines the parent directory of an object referenced in either a post request or query string, and ascertains whether the name of the directory could lead to security issues. Recommendation For Security Operations: One of the most important aspects of web application security is to restrict access to important files or directories only to those individuals who actually need to access them. The harder you make it for an attacker to access information about your web application, the more likely it is that he will simply find an easier target. Use the following recomendations to improve the security of your web application. • Restrict access to important files or directories only to those who actually need it. More information about implementing secure authentication schemes is listed below. • Enforce consistent authentication across your entire application. Ensure authentication is applied to the entire directory structure, including subdirectories. • Limit server-side includes only to trusted sources with adequate permissions. • Ensure that files containing sensitive information are not left publicly accessible. • Do not follow standard naming procedures for hidden directories. For example, don't create a hidden directory called "cgi" that contains cgi scripts. Obvious directory names are just that...readily guessed by an attacker. • Enforce a least privileges access policy. • Do not use robots.txt files, as most search engines and crawling/spidering tools do not honor them. For Development: Unless you are actively involved with implementing the web application server, there is not a wide range of available solutions to prevent problems that can occur from an attacker discovering underlying architectural information about your application. The nature of a web site is to be publicly accessible, which means the directory structure will also be so. Primarily, this problem will be resolved by the web application server administrator. However, there are certain actions you can take that will help to secure your web application and make it harder for an attacker to conduct a successful attack. • Ensure that files containing sensitive information are not left publicly accessible, or that comments left inside files do not reveal the locations of directories best left confidential. • Do not reveal information in pathnames that are publicly displayed. Do not include drive letters or directories outside of the web document root in the pathname when a file must call another file on the web server. Use pathnames that are relative to the current directory or the webroot. For QA: For reasons of security, it is important to test the web application not only from the perspective of a normal user, but also from that of a malicious one. Whenever possible, adopt the mindset of an attacker when testing your web application for security defects. Access your web application from outside your firewall or IDS. Utilize Google or another search engine to ensure that searches for vulnerable files or directories do not return information regarding your web application. For example, an attacker will utilize a search engine, and search for directory listings such as the following: 'index of / cgi-bin'. Make sure that your directory structure is not obvious, and that only files that are necessary are capable of being accessed.

I'm still confused how being able to access a JS file is an issue!

i am not sure why it is an issue either...it just just the folder where we store our js files...

Did you pay a consultant to run this scan, or is this just a tool you're running yourself?

government site I work on so some security group in our agency

It almost sounds like it is referencing a specific vulnerable js script in that directory that maybe has a cve or something…like a library or something

Maybe this is not about CORS, but more of a CSP thing?

Can you paste the part where it discloses the specifics of the issue? Like the file name, etc?

the url is https://sitename:443/scripts/utilities.js

A lot of these security scanner tools have some pretty vague stuff they will scan for, erroring on the side of false positives

and this info: Issue Details Kingdom: Environment Scan Engine: WEBINSPECT (Dynamic Analysis) CWE: CWE ID 527, CWE ID 538, CWE ID 548, CWE ID 552 Request GET /scripts/utilities.js?a=F6E002DC-FF3B-C8A9-BC2C1C2BE09BA183 HTTP/1.1 Host: stage-aces.faa.gov User-Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0 Accept: / Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Referer: https://stage-aces.faa.gov/index.cfm Pragma: no-cache Cookie: CFID=278144; CFTOKEN=4b9985523d7cc28b-F6DDBE9E-EA4ACC16- 8E7BB3886D309A54;CustomCookie=WebInspect194607ZXE1670A3C063D4E92A6714D3105DDEC54Y9562 Sec-Fetch-Dest: script Sec-Fetch-Mode: no-cors Sec-Fetch-Site: same-origin X-WIPP: AscVersion=22.2.0.253 X-RequestManager-Memo: stid="13";stmi="0";Category="EventMacro.StartMacro";MacroName="FAA+ACES+Pre+Prod+FCS+ (STAGE).webmacro"; X-Request-Memo: rid="e9ca17ca";thid="115"; Response HTTP/1.1 200 OK Content-Type: application/javascrip...TRUNCATED...

OK, that's better

sorry, what are you postinghere, this swe.mitre.org....

What is contained in that script

The question is really whether

/scripts/utilities.js

should be a path the browser can hit. I assume the answer is yes. And if that's the case, then this seems like a false positive to me.

yea read up on each of those CWE (weakness bs)

what is in the js file...a few js functions like formatting functions

that way everyone speaks the "same language" so to speak

ok...and as you know brad i don't speak the same language as you...LOL

So, like I said-- I'd kick this back to your security team. Tell them it's a JS file intended to be used by the browser, and there is no issue with it being publicly accessible.

that was one think Patrick said, so you are confirming that as an option as well...I will read the CWE stuff more and also tell my co workers on thursday about this and state it is probably a false posiive...

As I mentioned, it wouldn't hurt to apply some CSP headers to explain to browsers when it's ok to load the file, prevent other sites from loading your own script files and other dumb things like that. It might make the security people feel better anyway.

ok, i guess I could look into what to do with CSP headers...don't really know much about that or what to do with that...

I really wouldn't go down any rabbit trails until your security team proves exactly why this is a vuln. I understand people want to be helpful here and suggest things to try, but IMO it's really wasted effort unless it's actually what the security tool was specifically reporting. The report you shared says nothing at all about CORs or CSP

I concur

I can add that info the the jira ticket just so i have it in case they come back after discussion with them

At the least, you can read up and be ready

Management also tends to take security scans as "gospel truth" but if I had a dollar for every false positive I'd be pretty rich

Wait, you're not already rich?

LOL....thanks to all 3 of you for all your info on this...security stuff is not my expertise and have not had to look into it for years so just not sure what to do....

They keep adding "security stuff" unfortunately. So it's a continuing education challenge

and every time we have the scan run, new stuff is found...LOL

Kind of surprised a gov entity is allowing developers to also manage the server aspects; all agencies I work with have a server team that forces things like csp and cors and our apps have to deal with the rules.

yeah, we have almost cart blanc (sp) access to set up what we need on the aws server and cfml and most of this type of security stuff as far as I can tell...but the block us from using postman...I am just a grunt so I try to stay out of most of this stuff 🙂

The reason security teams think your js file is a security nightmare ready to hack and consume the soul of the server and everything else connected to it is that javascript files can be used for cross-site forgery requests, as well as somehow be replaced with a malicious code and then used to further propagate an attack. Both sides can argue about the need for security and/or using the file, and both are valid concerns. My suggestion is to wrap your javascript inside a cf file and be done with it.