In Mathias’ blog post,
unauthenticated XSS can also be exploited similar to the self-XSS issue but it
is less complicated. This is when a XSS
is not accessible to authenticated users. In that case, the attacker logs the
user out to deliver the XSS payload which waits for the user to authenticate in
another tab in order to perform the ultimate attack.
Recently, I found another similar
but rare example to perform CSRF attacks in a “secure” website that required
logging victims out and waiting for them to log back in later. Although this
case is not as common as the examples described by Matthias, it is still a
valid case to consider during an assessment.
The websites I was testing had an
anti-CSRF token in every POST requests that changed per-session, per-request,
and per-page. However, as the logout page used a GET request it was vulnerable
to CSRF attacks. The web application kept the anti-CSRF token value in the user’s
session on the server-side, and GET and POST requests were not interchangeable.
All was good until I realised that
some of the previously captured POST requests can be replayed with a new authenticated
session cookie if I remove the anti-CSRF token’s parameter from the body of the
POST request. I could however only send one token-less POST request to each
page as I received a security error afterwards. This showed that the website
was creating an anti-CSRF token for a page upon accessing the page for the
first time (there was also a page that could generate an anti-CSRF token for a
given page using AJAX but that is not important here).
As a result, I could not exploit this issue if the victim had already browsed a page that I wanted to target. However, as the logout page was vulnerable to CSRF attacks, I could exploit this issue by tricking the victim to visit a malicious website that would:
Send a malicious POST
request to the website without an anti-CSRF token’s parameter just in case I
was very lucky and the victim had not browsed that particular page (very unlikely
as it had a few pages)
Log the victim out of the
Keep sending the malicious
POST request without the anti-CSRF token’s parameter to perform an action in
the background until the user logs back in the target website in another browser
I recently had a presentation in the OWASP Birmingham (UK) chapter meeting. The crowd was very friendly, and it was a good experience overall with a lot of free food! I definitely recommend attending the next one if you are close by.
In my presentation, I showed a few examples how I managed to
win a lot of money in gambling games, cheated when doing my online shopping,
and got more free gifts than necessary! Obviously all of my actions were as
part of defined security assessments, and therefore I legally had the necessary
permissions to carry out my tests.
My presentation’s description was:
“I am going to review a number of interesting flaws that I have seen within the payment systems and gambling games. This includes examples that allowed me to win big while I was gambling very responsibly as well as simple methods that brought me free goods such as expensive books that I really didn’t need, fake moustaches, or even caskets for my fake funeral!
Disclaimer: all issues were reported responsibly to the companies and no moustache or slot machine was harmed in this process! I am not going to name any companies during this presentation.”
Its slides are available via the SlideShare website:
I was lucky enough to be on the voting panel despite having a nomination (I couldn’t vote for myself obviously). In the end, I felt honoured that my request encoding technique to bypass WAFs came in the Top 10 2017 (#8 to be exact). There were seriously good research works and I recommend you to check them out: Top 10 Web Hacking Techniques of 2017
I have always tried to share with the AppSec community as that also enable me to learn more by reading other people’s work or research. The last time I was on the Top 10 was 2009 for the IIS semicolon bug (remember file.asp;.txt bypass technique on IIS6?) so good to be back (#6): Top Ten Web Hacking Techniques of 2009 (Official)
Although there has always been discussions on the type of submissions such as techniques vs one time vulnerabilities as well as voting patterns, having a list of web related submissions is always useful and we now have it for 2017!