Hello,
I've failed latest PCI scan because of CVE-2009-0796. Centos 6.7. The Red Hat Security Response Team has rated this issue as having moderate security impact and bug as wontfix.
Explanation: The vulnerability affects non default configuration of Apache HTTP web server, i.e cases, when access to Apache::Status and Apache2::Status resources is explicitly allowed via <Location /perl-status> httpd.conf configuration directive. Its occurrence can be prevented by using the default configuration for the Apache HTTP web server (not exporting /perl-status).
I haven't used <Location /perl-status> but Trustwave still finds me vulnerable.
Evidence: Request: GET /perl- status/APR::SockAddr::port/"><script>alert('xss')</script> HTTP/1.1 Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: www.mydomain.com Content-Type: text/html Content-Length: 0 Response: HTTP/1.1 404 Not Found Date: Mon, 07 Aug 2015 11:10:21 GMT Server: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.3.3 Set-Cookie: PHPSESSID=kj6bpud7htmbtgaqtcwhsqk7j1; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre- check=0 Pragma: no-cache Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 Body: contains '"><script>alert('xss')</script>'
How can I get around this?
On Tue, Aug 11, 2015 at 4:46 AM, Proxy One proxy-one@mail.ru wrote:
I haven't used <Location /perl-status> but Trustwave still finds me vulnerable.
[...]
Response: HTTP/1.1 404 Not Found
You clearly aren't serving perl-status; that's a red herring here.
[...]
Body: contains '"><script>alert('xss')</script>'
That's your problem; they're flagging you for an XSS "vulnerability". I'm guessing you have a custom 404 page that naively echoes the entire request URL as part of the page? You need to be using htmlspecialchars() or HTML::Entities or whatever your language/environment has to escape strings for safe inclusion in HTML content.
There is of course more to it than that (sigh), try for starters: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Ch...
--ln
On 2015-Aug-11 19:57, Ellen Shull wrote:
On Tue, Aug 11, 2015 at 4:46 AM, Proxy One proxy-one@mail.ru wrote:
I haven't used <Location /perl-status> but Trustwave still finds me vulnerable.
[...]
Response: HTTP/1.1 404 Not Found
You clearly aren't serving perl-status; that's a red herring here.
Indeed, I don't have mod_proxy installed.
[...]
Body: contains '"><script>alert('xss')</script>'
That's your problem; they're flagging you for an XSS "vulnerability". I'm guessing you have a custom 404 page that naively echoes the entire request URL as part of the page? You need to be using htmlspecialchars() or HTML::Entities or whatever your language/environment has to escape strings for safe inclusion in HTML content.
There is PHP generated 404 page. I'll check that with web developer. What's strange, I'm trying to reproduce this and I don't see that string. Trustwave support suggested I use Burp Suite and it's repeater tool. I find some windows machine, installed it and all I see inside body is "Unable to resolve the request "perl-status/APR::SockAddr::port".
Is there way to use curl for testing? I'm getting new line because of the single quote inside string and escaping it with back slash gives me bash: syntax error near unexpected token `<'
There is of course more to it than that (sigh), try for starters: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Ch...
Very nice reading, thanks!
On Wed, Aug 12, 2015 at 3:39 AM, Proxy One proxy-one@mail.ru wrote:
Is there way to use curl for testing? I'm getting new line because of the single quote inside string and escaping it with back slash gives me bash: syntax error near unexpected token `<'
You can use curl's -K option which lets you stick arguments in a file, helpful for getting around shell quoting nightmares. For example make a file named test-url-file which contains the line url = http://www.mydomain.com/%5Bbad stuff, don't want this message tripping over some filter for containing a malicious-looking URL]
then do curl -g -K test-url-file
Note that just gets you around shell interpretation; curl does some of its own as well. the -g switch I used there disables its interpretation of {}[] as special globbing characters. If you put the url in double quotes then not only do you have to escape any double quotes in the string, it also starts interpreting backslash sequences so you have to double all backslashes--so oddly it's best to just leave quotes off.
--ln
On 2015-Aug-12 05:17, Ellen Shull wrote:
On Wed, Aug 12, 2015 at 3:39 AM, Proxy One proxy-one@mail.ru wrote:
Is there way to use curl for testing? I'm getting new line because of the single quote inside string and escaping it with back slash gives me bash: syntax error near unexpected token `<'
You can use curl's -K option which lets you stick arguments in a file, helpful for getting around shell quoting nightmares. For example make a file named test-url-file which contains the line url = http://www.mydomain.com/%5Bbad stuff, don't want this message tripping over some filter for containing a malicious-looking URL]
then do curl -g -K test-url-file
Note that just gets you around shell interpretation; curl does some of its own as well. the -g switch I used there disables its interpretation of {}[] as special globbing characters. If you put the url in double quotes then not only do you have to escape any double quotes in the string, it also starts interpreting backslash sequences so you have to double all backslashes--so oddly it's best to just leave quotes off.
Thanks, it works! I was able to reproduce problem and was able to see how my changes affected response from the server.
How about something like:
<Location /perl-status>
# disallow public access Order Deny, Allow Deny from all Allow from 127.0.0.1
SetHandler perl-script PerlResponseHandler Apache2::Status </Location>
2015-08-11 14:46 GMT+03:00 Proxy One proxy-one@mail.ru:
Hello,
I've failed latest PCI scan because of CVE-2009-0796. Centos 6.7. The Red Hat Security Response Team has rated this issue as having moderate security impact and bug as wontfix.
Explanation: The vulnerability affects non default configuration of Apache HTTP web server, i.e cases, when access to Apache::Status and Apache2::Status resources is explicitly allowed via <Location /perl-status> httpd.conf configuration directive. Its occurrence can be prevented by using the default configuration for the Apache HTTP web server (not exporting /perl-status).
I haven't used <Location /perl-status> but Trustwave still finds me vulnerable.
Evidence: Request: GET /perl- status/APR::SockAddr::port/"><script>alert('xss')</script> HTTP/1.1 Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: www.mydomain.com Content-Type: text/html Content-Length: 0 Response: HTTP/1.1 404 Not Found Date: Mon, 07 Aug 2015 11:10:21 GMT Server: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.3.3 Set-Cookie: PHPSESSID=kj6bpud7htmbtgaqtcwhsqk7j1; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre- check=0 Pragma: no-cache Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 Body: contains '"><script>alert('xss')</script>'
How can I get around this? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 2015-Aug-12 07:36, Eero Volotinen wrote:
How about something like:
<Location /perl-status>
# disallow public access Order Deny, Allow Deny from all Allow from 127.0.0.1 SetHandler perl-script PerlResponseHandler Apache2::Status</Location>
Thanks to this I noticed that I don't have mod_perl installed at all. So even this vulnerability is marked as CVE-2009-0796, it's related to my 404 page.
Thanks!
2015-08-11 14:46 GMT+03:00 Proxy One proxy-one@mail.ru:
Hello,
I've failed latest PCI scan because of CVE-2009-0796. Centos 6.7. The Red Hat Security Response Team has rated this issue as having moderate security impact and bug as wontfix.
Explanation: The vulnerability affects non default configuration of Apache HTTP web server, i.e cases, when access to Apache::Status and Apache2::Status resources is explicitly allowed via <Location /perl-status> httpd.conf configuration directive. Its occurrence can be prevented by using the default configuration for the Apache HTTP web server (not exporting /perl-status).
I haven't used <Location /perl-status> but Trustwave still finds me vulnerable.
Evidence: Request: GET /perl- status/APR::SockAddr::port/"><script>alert('xss')</script> HTTP/1.1 Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: www.mydomain.com Content-Type: text/html Content-Length: 0 Response: HTTP/1.1 404 Not Found Date: Mon, 07 Aug 2015 11:10:21 GMT Server: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.3.3 Set-Cookie: PHPSESSID=kj6bpud7htmbtgaqtcwhsqk7j1; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre- check=0 Pragma: no-cache Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 Body: contains '"><script>alert('xss')</script>'
How can I get around this? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Eero Volotinen -
Ellen Shull -
Proxy One -
Прокси