Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 608
  • Last Modified:

ASP.Net Debug vulnerability preventing PCI Compliance HELP!

Our PCI Compliance vendor is failing our scans saying that we have ASP.Net Debugging enabled and that scanning results in an "HTTP Status Code 200 OK" rather than the expected 400 Bad Request, 405 Method Not Allowed, or 501 Not Implemented message.

I have gone through and modified the Machine.Config files to add the <deployment retail="true"/> line as specified in http://msdn.microsoft.com/en-us/library/system.web.configuration.deploymentsection.retail(v=vs.110).aspx but they are still saying that a Status 200 OK is being returned.

The PCI vendor reference me to http://support.microsoft.com/default.aspx?scid=kb;en-us;815157 but it clearly says that disabling debugging using the machine.config file overrides debugging enabled in individual web.config files.

We are trying to avoid having to set this configuration in our 200 or so web.config files of which many are different. Has anyone dealt with this or have any insight to he me with this? Is this a known issue with disabling debugging using the retail mode method in the machine.config file?
0
AIC-Admin
Asked:
AIC-Admin
  • 3
  • 2
1 Solution
 
käµfm³d 👽Commented:
We are trying to avoid having to set this configuration in our 200 or so web.config files
Well why are you deploying production code with the debug flag enabled? It's called "debug" for a reason.

The web.config files are just XML files. It really wouldn't be that hard to script or write a quick app to traverse all of your directories and remove debugging from each file.
0
 
AIC-AdminAuthor Commented:
I do not develop the websites (I'm just the network admin) but I was told by our lead developer that when they deploy code from development to production that they frequently deploy new web.config files. We run ASP.Net version 2 in 32-bit and 64-bit and ASP.Net version 4 in 32-bit and 64-bit. We have numerous web applications as well so we could end up with hundreds of web.config files across our 14 or so app servers.

I will see if our developers can or know how to do what you recommended... write a script or quick app to traverse all of our directories and remove debugging from each file. I assume that would consist of searching for all files named "web.config" then searching the contents of those files for <compilation debug="true"/> and if found changing it to "<compilation debug="false"/>.
0
 
käµfm³d 👽Commented:
Correct.
0
 
käµfm³d 👽Commented:
You can try the following VBScript file if you like. Copy the code into a new text file, and give it a ".vbs" extension. Then you can simply double-click the new file to run it.

You would need to change the first to lines to something more appropriate--change what's inside the quotes, nothing else. The code will copy the original web.config files--maintaining their hierarchy as found in the source folder--to a backup folder before modifying them. Then you can compare to see which files were modified, or restore any that you may need.

If you do decide to use this, MAKE A BACKUP OF YOUR SOURCE FOLDER FIRST! I don't foresee any issue with this code, but it's better to be safe than sorry.

'WWWROOT = "C:\path\to\your\site\top\level\folder"
'BACKDIR = "C:\path\to\a\folder\where\you'll\copy\backups"



' ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'  Script Start
' ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Set FSO = CreateObject("Scripting.FileSystemObject")
Set ROOT = fso.GetFolder(WWWROOT)

If Not fso.FolderExists(BACKDIR) Then
  fso.CreateFolder(BACKDIR)
End If

Set BACK = fso.GetFolder(BACKDIR)

Call ProcessFolder(ROOT, BACK)

' ######################################
'  Functions
' ######################################

Sub ProcessFolder(ByVal target, ByVal backup)
    For Each file in target.Files
        Call ProcessFile(file, backup)
    Next

    For Each fold In target.SubFolders
        backFoldPath = backup.Path & "\" & fold.Name
        
        If Not FSO.FolderExists(backFoldPath) Then
            FSO.CreateFolder(backFoldPath)
        End If
        
        Set backFold = FSO.GetFolder(backFoldPath)
        
        Call ProcessFolder(fold, backFold)
    Next
End Sub

Sub ProcessFile(ByVal target, ByVal backup)
    FSO.CopyFile target.Path, backup.Path & "\" & target.Name

    Set xdoc = CreateObject("Msxml2.DOMDocument.6.0")
    
    xdoc.Load target.Path
    
    Set compilationNode = xdoc.SelectSingleNode("/configuration/system.web/compilation")
    
    If Not compilationNode Is Nothing Then
        compilationNode.RemoveAttribute("debug")
        xdoc.Save(target.Path)
    End If
End Sub

Open in new window

0
 
AIC-AdminAuthor Commented:
Thank you for providing this code! I will keep this for future use.

We ended up writing an "iRule" on our F5 Load Balancer to identify inbound DEBUG requests and automatically reply with a "http 403 forbidden" response which has resolved the issue.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now