# 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?
LVL 3
###### 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.

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.
Author 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"/>.
Commented:
Correct.
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")

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


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.

Author 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
Security

From novice to tech pro — start learning today.