Safecracker forms fail PCI DSS

Question

On our site we have a number of front-end Safecracker forms. Also, our website needs to be fully PCI DSS compliant and in order to achieve this, we have to use a scanning tool provided by our Merchant Bank to ensure that any vulnerabilities are fixed before they will supply us with a PCI DSS compliance certificate.

When we scanned our website, all of the safecracker forms came up with the following similar warning;

Description: CGI Generic Cross-Site Scripting (quick test)

Synopsis: The remote web server is prone to cross-site scripting attacks.

Impact: The remote web server hosts CGI scripts that fail to adequately sanitize request strings with malicious JavaScript. By leveraging this issue, an attacker may be able to cause arbitrary HTML and script code to be executed in a user's browser within the security context of the affected site. These XSS are likely to be 'non persistent' or 'reflected'.

See also : http://en.wikipedia.org/wiki/Cross_site_scripting#Non-persistent http://www.nessus.org/u?9717ad85 http://projects.webappsec.org/Cross- Site+Scripting

Data Received: Using the POST HTTP method, SecurityMetrics found that :

• The following resources may be vulnerable to cross-site scripting (quick test) :

• The 'RET' parameter of the /product-registration CGI :

/product-registration [RET=<IMG SRC="javascript:alert(104);">]

-------- output -------- <p>&nbsp;</p>

<form id="publishForm" method="post" action="<IMG SRC="javascript:alert( 104);">" enctype="multipart/form-data" > <div class='hiddenFields'> <input type="hidden" name="ACT" value="108" /> ------------------------ Other references : CWE:79, CWE:80, CWE:81, CWE:83, CWE:20, CWE:74, CWE:442, CWE:712, CWE:722, CWE:725, CWE:811, CWE:751, CWE:801, CWE:116, CWE:692, CWE:86 

Another example of vulnerability with the same form is as follows;

-------- output -------- <p>&nbsp;</p>

<form id="publishForm" method="post" action="509" src="http://www.exampl e.com/exploit509.js" enctype="multipart/form-data" > <div class='hiddenFields'> <input type="hidden" name="ACT" value="108" /> ------------------------ /product-registration [return_url=/product- registration/sent&RET=509" sr c="http://www.example.com/exploit509.js&XID=]

-------- output -------- <p>&nbsp;</p>

<form id="publishForm" method="post" action="509" src="http://www.exampl e.com/exploit509.js" enctype="multipart/form-data" > <div class='hiddenFields'> <input type="hidden" name="ACT" value="108" /> ------------------------ Other references : CWE:79, CWE:80, CWE:81, CWE:83, CWE:20, CWE:74, CWE:442, CWE:712, CWE:722, CWE:725, CWE:811, CWE:751, CWE:801, CWE:116, CWE:692, CWE:86 

Resolution: Restrict access to the vulnerable application. Contact the vendor for a patch or upgrade.

Risk Factor: Medium/ CVSS2 Base Score: 4.3

AV:N/AC:M/Au:N/C:N/I:P/A:N

I was wondering if anyone else has come across this before with ExpressionEngine and Safecracker forms? And also, what the fix(es) might be?

As mentioned in a reply below, I do have the 'return' and 'return_url' parameters set for the form.

Thanks.

Answer 1

Security scans are a joyous thing. And often return "false positives". Unfortunately in the PCI world, they don't care. It looks like the scanner is referring to the return parameter and being able to inject something into the hidden field. I just checked and SC adds a return parameter of the current page if you don't supply one. So the hidden field is still there.

Can the scanner provide more info, i. e. what it tried to inject? What was returned to it? That may give you a bit more to go on.

I don't believe EE comes close to making any such claims of being PCI compliant.

I would suggest looking at the SC module and see if you can find where it processes the return parameter. Maybe there you can see what you need to add to scrub the return parameter.

Not sure, but you may find your self going down the line of all the hidden parameters as you continue scanning.