Web application -- Security Issue

The web application exposes the presence of the following site directories in view source.
a)     /app
b)     /scripts

e.g.  <script src="/scripts/JSBundle?v=MPLXzkm07-7hkW9Seha1pOPCgFUXV"></script>

This folder details can be used in attacks.

what can we do so that site folder names are not exposed and still allow site to work.

The site is created in asp.net and hosted on IIS

Dinesh KumarAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

käµfm³d 👽Commented:
Are you sure this is a concern? If you're folders are that sensitive, then in my opinion you are putting things in the wrong directories. What makes you think this is a security concern?
Can you list those directories? If not there is no concern, if you can - you need to disable listings.
btanExec ConsultantCommented:
Control search engine crawlers with robots.txt file - e.g. use option such as in .txt
Disallow: sets the files or folders that are not allowed to be crawled. http://www.inmotionhosting.com/support/website/restricting-bots/how-to-stop-search-engines-from-crawling-your-website

Configure <authorization> elements within your application's Web.config file to control which users and groups of users should have access to the application. You don't need to impersonate for URL authorization to work. In ASP.NET 2.0, URL authorization applies to all files under the given folder. The Web.config usually refer to all of the files in the current directory and all subdirectories (unless a subdirectory contains its own Web.config with an <authorization> element. E.g. to prevent all access to a folder:
<?xml version="1.0" encoding="utf-8"?>
            <deny users="*" />
Your site permissions will be included in the site’s files themselves.

Consider using the HttpForbiddenHandler for files that your application uses internally, but are not intended for download. Also secure the files with Windows ACLs to control which users can access the files, when logged on to the Web server.

Not neglect the standard to add NTFS permissions to the share's folder. Also need to set the share's permissions to grant at least read access to either the ASP.NET process account or the impersonated identity (if your application is configured for impersonation).
To give Read, Execute, and Write permissions to MyApp file system directory for user Foo, add the following line to the Manifest.xml file:
<setAcl path=”MyApp” setAclAccess=”ReadAndExecute, Write” setAclUser=”Foo” />

To set the ACL on the path MyApp/Upload to allow anonymous users to upload content, add the following line to your Manifest.xml file:
<setAcl path=”MyApp/Upload” setAclAccess=”Write” setAclUser=”anonymousAuthenticationUser” />

Note that anonymousAuthenticationUser is a special token that will resolve to your configured anonymous authentication identity.

To grant Read access to the MyApp\Data folder for the application pool identity, add the following line to the Manifest.xml file:
<setAcl path=”MyApp/Data” setAclAccess=”Read” />

Disable directory browsing https://technet.microsoft.com/en-us/library/cc731109(v=ws.10).aspx
Need More Insight Into What’s Killing Your Network

Flow data analysis from SolarWinds NetFlow Traffic Analyzer (NTA), along with Network Performance Monitor (NPM), can give you deeper visibility into your network’s traffic.

David Johnson, CD, MVPOwnerCommented:
those areas are required for the browser to work if they are referenced in your webpages
Dinesh KumarAuthor Commented:
let me ask in other ways:

The web application exposes the presence of site directories. This can inadvertently provide details about the application that can be used in attacks.


The web application exposes the presence of the following site directories:
a)     /app
b)     /scripts
c)      /stylesheets
This can inadvertently provide details about the application that can be used in attacks.

a note, These folder are displayed when we see view source of html page.
David Johnson, CD, MVPOwnerCommented:
scripts and stylesheets and perhaps app ARE required items that if you block access to them you will break the website if ANY webpage requires an item available in those directories.  You can't just follow security guidelines blindly they are just guidelines..
a .css file or a .js file don't reveal anything.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
käµfm³d 👽Commented:
Those are standard folders for almost any web application/page. I fail to see how those particular directories would give an attacker any more information than simply guessing that those folders exist. Honestly, I think your concern if unfounded. btan's information above would be more prudent for you, I think.
btanExec ConsultantCommented:
good to review on the "need to" basis and least privileged principles to tighten the folder access so that the apps also do not "break" unnecessarily due to access denial.
Dinesh KumarAuthor Commented:
I just talked with a  Security people, they said its the standard to not show any folder to Browser.
Dinesh KumarAuthor Commented:
I just talked with a  Security people, they said its the standard to not show any folder to Browser in view source currently app, js and stylesheets.

Do we have any way to not show them and still the site works.
Dave BaldwinFixer of ProblemsCommented:
I just talked with a  Security people, they said its the standard to not show any folder to Browser.
I'm sorry but that is not even possible.  You need to go look at the "View Source" of a lot web sites so you can see that every folder that contains files used in the web page is listed in the HTML content.  Start with this page.  There are folder links for 'articles', 'videos', 'members', 'Expert_Testing', and "/topics/security/", "/topics/microsoft-iis-web-server/", "/topics/asp-net/".
It is standard to have images in images/ folder (or on different domain for big sites like Google)
There is no easy way to scramble content so that no folders are shown in page source (or static resources being loaded from constant URL)
btanExec ConsultantCommented:
What is the security control if directory browsing is disabled and the site goes through security testing sanctioning it clear at that instance on clear state for existence of web vulnerability esp like remote file inclusion (RFI) or equivalent. they are all attempts to reach a file but close up. Hardening is a better scheme rather than "obscurity". The folder permission can still be considered as I shared to allow read. But to totally hide that I that can break the apps - so what is the security tm concern and knowing the threat use case will be good.

Note that even web page will load script and images etc to run and browser hover over may also show it  under properties (right click on object) on the "Address (URL)". That to me is also revealing too..
Dinesh KumarAuthor Commented:
Yes.. they are standard folders and It does not make sense to hide them however I need to check them manually those JS files if there is any sensitive information is there to close this.
Thank you.
Shalom CarmelCTOCommented:
I just talked with a  Security people, they said its the standard to not show any folder to Browser in view source currently app, js and stylesheets.
This is an absurd requirement and not a true statement.
The only case when having the directory structure hidden makes sense, is for SEO reasons, and even then only for the content page URL, not for the components.

However, if the security people REALLY insist, then the solution would be to create internal rewrite rules for each and every file to be accessed from these directories.

for example, in the rewrite rules you map

*.css => /stylesheets/*.css
When you open source of this page you see:
<link href='//fonts.googleapis.com/css?family=Open+Sans:400,300,700' rel='stylesheet' type='text/css'>
    <link rel="stylesheet" href="//experts.cachefly.net/css/2/46ee452ed928e168329ba188ab99c7181881a71c366ba69a84ff17bc23521433.css" media="all" />
    <link rel="stylesheet" href="//experts.cachefly.net/css/2/6fd7990c7b61f291d70767fcf90ff88c92a1571fcafdabed97d3ee6041590c27.css" media="all" />
    <script src="//experts.cachefly.net/js/2/d487b0d4d961a96067ced6f47d2cc74d5c1046a073b76c1a7e9d6e98962617ef.js" type="text/javascript"></script>
    <script src="//experts.cachefly.net/js/2/9a393723cc0e5612ef7741131d89453bb9bb8abcaf08697ce0380119a5d2ca52.js" type="text/javascript"></script>

Open in new window

You mean e-e is insecure?
btanExec ConsultantCommented:
the js folder will depends on your application file but if you say the standard jquery js file then I do not see any sensitive. As mentioned, it is not effective to hide as security concerns is probably to deny access and if you pass online security checks such as sitecheck (https://sitecheck.sucuri.net//) or what your security team proposed to check against the web scanner tools, I do not see any further hardening except from your app codes. the source .cs should not be in those standard folder and remove from public access. Only the assembled and compile dll are likely loaded but not retrieved to client.

As prev mentioned, hardening is key to be holistic rather than pinpoint specific perceived "gap" per se. Do consider review it as a whole, can check on Urlscan v3.0 and using URL Rewrite to Prevent Image Hotlinking for further tightening esp for self-containment of service and only within the site and not external site. The others are as per the authz stated. It is pretty tough to stop access for the sake of security if the latter is a false positive when all low hanging risk are closed. The admin and user internal access control of the web server is separate discussion from public access  
David Johnson, CD, MVPOwnerCommented:
what you can do is move contents of these folders into the websites root directory and delete the folders.. you will now have to go through your source and change ALL of the links to point to the website root folder. This won't change the security one iota but will make your security people happy, frustrate your web developers..
käµfm³d 👽Commented:
I just talked with a  Security people, they said its the standard to not show any folder to Browser.
I'm thinking that by this they are referring to directory browsing.
David Johnson, CD, MVPOwnerCommented:
yes you should have directory browsing disabled, ask them if this is what they mean.
btanExec ConsultantCommented:
then security folks is not clear in the required then, it is all part of hardening as mentioned so earlier upfront in the posting ... urlscan lockdown the fundamental and if they really needs compliance then establish the baseline using CIS standards...but compliance does not mean secured.
If you go to directory /stylesheests/ - do you see directory listing with files or some error?
Dinesh KumarAuthor Commented:
Thank you all for your timely support.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.