Home page logo

webappsec logo WebApp Sec mailing list archives

[Fwd: London WAF event - Addidional vulnerabilities]
From: Dinis Cruz <dinis () ddplus net>
Date: Mon, 24 Apr 2006 23:10:34 +0100

Here are a couple more interesting vulnerabilities from HacmeBank (Note:
most are not mentioned in the Foundstone HacmeBank 2.0 User Guide pdf)


-------- Original Message --------
Subject:        London WAF event - Addidional vulnerabilities

Dear F5, Imperva, NetContinuum, Fortify and Breach

Following the positive response (from some of you) regarding the
successful mitigation of most of the vulnerabilities included on my last
email, here are 6 additional vulnerabilities (harder to mitigate):

    Vulnerability: Users are able to access account details belonging to
other users:
    Exploit: log-in as user jv and open the page
    replace the 'account_no' GET value with 5204320422040003 (i.e.
and note that you are now accessing account details belonging to another
user (in this case the user jm)

    Vulnerability: Old Password requirement is not enforced in 'Change
Password' page    
    Exploit: Hijack user session (using for example a valid user's
Session Cookie), open the page and change
that user's password (without knowledge of that user's current password)

    Vulnerability: ViewState replay vulnerability
    Exploit: The source account on the Transfer Funds page
( is
controlled by ViewState. This means that the attacker cannot change this
value by POST form injection, but means that if the attacker is able to
grab a valid ViewState from another user (via Xss, cached copy of that
page on a Hard Disk or by sniffing the traffic), it can replay that
ViewState and make transfers from that account (to an external account).

    Vulnerability: Web Services Session ID is not enforced
    Exploit: Invoke the web services directly without needing a valid
    Solution: the correct resolution of this vulnerability is one where
the Web Services are still publicly available but control to the exposed
Web Services functionality is managed via the SessionID

    Vulnerability: 'WAF redirect on attack detection' information leak
    Exploit: The normal WAF functionality of redirecting attacks
detected to a custom error pages, provides information to attackers that
such type of defense (WAF) is in use, and creates very dangerous 'False
Positive' situations where valid user's input could be wrongly flagged -
something that would severely affect the user experience and business
value (imagine a user filling a 4 page web form being redirected to the
error page on the last page).
    Solution: Dynamically 'normalize' potentially malicious input. For
example, on a Form field vulnerable to SQL Injection, rewrite that field
with only the allowed chars (for example letters and numbers) and flag
an attack

    Vulnerability: "How do we know we are being attacked?"
    Exploit: Attack the website via 1) the vulnerabilities that are not
'patched' or 2) pages not protected by WAF (i.e. with no rules applied)
    Solution: Alert WAF operational staff when such attacks are occurring

Finally here is one last question and demo request: "If your WAF has a
Web Interface, are you able to protect it using your WAF?"

After all presentations are done, there will be Panel Discussion (with a
representative from each WAF vendor) where we will discuss ideas and
solutions for the mitigation of the most complex vulnerabilities.

Best regards

Dinis Cruz
Owasp .Net Project

Sponsored by: Watchfire

Watchfire's AppScan is the industry's first and leading web application 
security testing suite, and the only solution to provide comprehensive 
remediation tasks at every level of the application. Change the way you 
think about application security testing - See for yourself. 
Download a Free Trial of AppScan 6.0 today!


  By Date           By Thread  

Current thread:
  • [Fwd: London WAF event - Addidional vulnerabilities] Dinis Cruz (Apr 25)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]