Jun 12th, 2015, 12:26 PM
(This post was last modified: Jun 23rd, 2015, 7:24 AM by michatmaster7.)
Recently, a PCI audit revealed a cross site scripting vulnerability in some of the forms I had developed for my clients. If I understand the terminology correctly, it is based on PHP Injection. Basically, since the form action of an external form (utilizing the API) is:
Then the URL can be used to execute scripts as variables in the URL.
There's ample documentation about this being a well known problem. There are also lots of forums around the WWW with potential fixes.
Since I don't pretend to understand PHP as a programming language, I have to have assumed that Joe and Ben intended the form action for a reason. And then I read the tutorial on adding a single page form with the API. It was then that I realized the form action being PHP_SELF was only out of convenience to the web developer. For example, we could, instead, use the file path as the form action, but if we ever changed the file path (or it's filename), we would need to remember to change the form action, as well.
That said, I have now opted to edit all of my external forms to utilize a hard-coded form action URL, like this:
Obviously, you would want to replace domain and filename with your own values.
While the tutorial I mentioned above actually states:
It is actually better if you use the name of the file, to prevent potential XSS attacks on the form submission. You'll just need to remember to change the form action if the name of the file changes.
Before I realized all of this, I DID actually come across another potential solution, which should prevent the URL from being appended. However, I'm also fairly certain the code I found is bloated a bit, since it wasn't programmed specifically for FormTools. I just don't know PHP well enough to strip it down. It does, however, prevent the PCI scans from flagging the XSS vulnerability.
I would like to actually store this code in a separate file and call the file from the top of all of my forms, for convenience, but I'm not entirely sure how to do that, either. This is really sort of irrelevant now, though, since I'm now using the full path in the form's action attribute, instead of PHP_SELF.
If this code could be tested by Ben/Joe, perhaps it could be implemented in the core, to help prevent XSS attacks on forms utilizing the API. The code I found is:
Hopefully this all makes sense to someone.
PHP Code:
<form action="<?php echo $_SERVER["PHP_SELF"]?>" method="post">
Then the URL can be used to execute scripts as variables in the URL.
There's ample documentation about this being a well known problem. There are also lots of forums around the WWW with potential fixes.
Since I don't pretend to understand PHP as a programming language, I have to have assumed that Joe and Ben intended the form action for a reason. And then I read the tutorial on adding a single page form with the API. It was then that I realized the form action being PHP_SELF was only out of convenience to the web developer. For example, we could, instead, use the file path as the form action, but if we ever changed the file path (or it's filename), we would need to remember to change the form action, as well.
That said, I have now opted to edit all of my external forms to utilize a hard-coded form action URL, like this:
PHP Code:
<form action="https://www.domain.com/filename.php" method="post">
Obviously, you would want to replace domain and filename with your own values.
While the tutorial I mentioned above actually states:
Quote:It's generally a better idea to use $_SERVER["PHP_SELF"] instead of the name of the file, since filenames sometimes change. If that happens, you'd need to remember to update the action attribute. But by using the PHP variable, you don't have to worry about it!
It is actually better if you use the name of the file, to prevent potential XSS attacks on the form submission. You'll just need to remember to change the form action if the name of the file changes.
Before I realized all of this, I DID actually come across another potential solution, which should prevent the URL from being appended. However, I'm also fairly certain the code I found is bloated a bit, since it wasn't programmed specifically for FormTools. I just don't know PHP well enough to strip it down. It does, however, prevent the PCI scans from flagging the XSS vulnerability.
I would like to actually store this code in a separate file and call the file from the top of all of my forms, for convenience, but I'm not entirely sure how to do that, either. This is really sort of irrelevant now, though, since I'm now using the full path in the form's action attribute, instead of PHP_SELF.
If this code could be tested by Ben/Joe, perhaps it could be implemented in the core, to help prevent XSS attacks on forms utilizing the API. The code I found is:
PHP Code:
// XSS prevention
if (isset ($_SERVER['ORIG_PATH_INFO']) && $_SERVER['ORIG_PATH_INFO'] != $_SERVER['PHP_SELF']) {
$_SERVER['PATH_INFO'] = $_SERVER['ORIG_PATH_INFO'];
}
// Security measure, to avoid XSS exploit.
if (!empty ($_SERVER['PATH_INFO']) && strrpos ($_SERVER['PHP_SELF'], $_SERVER['PATH_INFO'])) {
$_SERVER['PHP_SELF'] = substr ($_SERVER['PHP_SELF'], 0, -(strlen ($_SERVER['PATH_INFO'])));
}
Hopefully this all makes sense to someone.