bugtraq - Prado TJavaScript::encode() script injection vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <201203221225.q2MCPT42030200@sf01web3.securityfocus.com>
Date: Thu, 22 Mar 2012 12:25:29 GMT
From: gabor.berczi@...worx.hu
To: bugtraq@...urityfocus.com
Subject: Prado TJavaScript::encode() script injection vulnerability

Prado TJavaScript::encode() script injection vulnerability

Vulnerability severity                  : medium
Vulnerability type                      : cross-site script injection attack
					  cookie theft
					  session hijacking
					  stealing of sensitive information

Remotely exploitable                    : yes

Vulnerability discovery date            : 2012/03/07
Vulnerability discovered by             : Gabor Berczi <gabor.berczi@...worx.hu>

Proof of concept exploit created        : 2012/03/11
Proof of concept exploit developed by   : Gabor Berczi <gabor.berczi@...worx.hu>

Fix created        			: 2012/03/07
Fix developed by   			: Gabor Berczi <gabor.berczi@...worx.hu>

Vulnerability reported to vendor        : 2011/03/07

Affected products                       : PRADO (PHP Framework) 3.x

Summary:

The vulnerability allows injection of arbitrary JavaScript snippets into some of the 
standard controls built into PRADO, if the latter try to display or use string type 
information that begins with user-supplied data fragments. This can be used by a remote
attacker to hijack a victim's session and steal sensitive information.

The vulnerability exists because the affected standard controls do not escape user-supplied
textual information properly when rendering the JavaScript code for their client-side wrappers, 
and because the PRADO Framework provides currently no way for the application or component 
developers to supply textual information to said controls in an XSS-safe way. The latter also
means that several 3rd party components or application might be also affected by the issue,
even if they don't use any of the vulnerable standard controls, but pass information the same
way to the client-side as the former do.

A fix has been already provided for the vulnerability, alongside with a PoC exploit.

http://code.google.com/p/prado3/issues/detail?id=391