Hello,

We have a DNN v7.4.0 (client's) website that has recently failed a SecurityMetrics PCI compliance scan based on "Source code disclosure". The scan failure is listed below at the bottom of this thread post. The issue we are seeing with this particular failure is that the use of the script call to /Telerik.Web.UI.WebResource.axd is a common DNN core practice, and not really a source code disclosure? Additionally, the same goes for the LinkClick.aspx usage. Seems the "Resolution" as listed in the report below is not feasible given the core nature of DNN? Any thoughts on how to rectify this so we can get a clean PCI compliance scan on both accounts; or, how we might argue that it's not a vulnerability point in either case? Any details/assistance would be great. Thank you.

Title: Source code disclosure\
Impact: A modern web application will be reliant on several different programming languages. These languages can be broken up into two flavours. These are client side languages such as those that run in the browser eg. JavaScript and HTML, and server side languages that are executed by the server (ASP, PHP, JSP, etc) to form the dynamic pages (client side code) that are then sent to the client. Because all server side code should be executed by the server, it should never be seen by the client. However in some scenarios, it is possible that 1. The server side code has syntax errors and therefore is not executed by the server but is instead sent to the client, or 2. Using crafted requests it is possible to force the server into displaying the source code of the application without executing it. As the server side source code often contains sensitive information such as database connection strings or details into the application workflow this can be extremely risky. Cyber-criminals will attempt to discover pages that either accidentally or forcefully allow the server side source code to be disclosed, to assist in discovering further vulnerabilities or sensitive information. SecurityMetrics has detected server side source code within the server's response. Note: false positives may occur when requesting binary files such as images (.JPG or .PNG) and may require manual verification. Affected URL: http://www.MYDOMAIN.org/Telerik.Web.UI. WebResource.axd_?_TSM_CombinedScripts_=;;System.Web.Extensions,+Version=4.0.0.0,+Culture=neutral,+PublicKeyToken=31bf3856ad364e35:en-US:88fd0407 -24cf-4abd-9df5-22f81b2bc835:ea597d4b:b25378d2;Telerik.Web.UI,+Version=2013.2.717.40,+Culture=neutral,+PublicKeyToken=121fae78165ba3d4:en- US:a713c6a1-0827-4380-88eb-63855ca4c2d9:16e4e7cd:b7778d6c&_TSM_HiddenField_=ScriptManager_TSM&compress=1 Affected Variable: _TSM_HiddenField_ 
Injected text: /Default.aspx%00. Variation ID: Response.Write\
Resolution: If confirmation reveals the leakage of server side source code, then the following remediation actions should be applied. Determine the context in which the source code is disclosed. ie. Caused through coding errors, or abusing existing functionality. If due to errors in the server side code, then the code causing the disclosure should be rewritten. If it is through the abuse of existing functionality then it is important that input sanitisation be conducted to prevent application files (ASP, JSP, PHP or config files) from being called. It is also important that the file system permissions are correctly configured, and that all unused files are removed from the web root. If these are not a
option, then the vulnerable file should be removed from the server.\
Risk Factor: High/ CVSS2 Base Score: 10.0\

ALSO FAILED WITH SAME TITLE, IMPACT, RESOLUTION & RISK FACTOR AS ABOVE: Affected URL: http://www.MYDOMAIN.org/LinkClick.aspx?fileticket=yn550bvwEog=&tabid=55&portalid=0&mid=762 Affected Variable: mid Injected text: /Default.aspx Variation ID: %3C%25

The linkclick item is also a false-positive. “Linkclick’s” primary use case is to allow access to files to be restricted to certain users/roles. When a file is in a secure folder (either standard or database), then access to it is exclusively through linkclick.aspx. The linkclick code will analyse the request and then get the required file. Just before the file is written out (i.e for display or download), a check is made to ensure that the user in question is allowed access to that folder , and if so then the file is streamed down. If they are not then an exception is thrown. You can see this at this point in the code:

https://github.com/dnnsoftware/Dnn.Pl...

The reason you’re seeing a warning from SecurityMetrics is that the FileServerHandler (the http handler that processes linkclick’s), has code to extract various values, including “mid” (which is used to identify the module where the url is stored) . If the “mid” variable is not an integer an exception is thrown – for some reason SecurityMetrics believe this indicates a potentially “hackable” variable, but it’s not an issue, as no matter what parameters are used the user’s folder permissions are always validated

You can see the relevant code at:

https://github.com/dnnsoftware/Dnn.Platform/blob/7fae41929b69001a1efe0bb9c372af14c67129b7/DNN%20Platform/Library/Services/FileSystem/FileServerHandler.cs#L75