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 but they are still saying that a Status 200 OK is being returned.

The PCI vendor reference me to;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?
Who is Participating?
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.

kaufmed   ( ⚆ _ ⚆ )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.
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"/>.
kaufmed   ( ⚆ _ ⚆ )Commented:
kaufmed   ( ⚆ _ ⚆ )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
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)

    For Each fold In target.SubFolders
        backFoldPath = backup.Path & "\" & fold.Name
        If Not FSO.FolderExists(backFoldPath) Then
        End If
        Set backFold = FSO.GetFolder(backFoldPath)
        Call ProcessFolder(fold, backFold)
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
    End If
End Sub

Open in new window

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
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.
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.