Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Parameter fuzzing and forced browsing |
|---|---|
| Date: | Thu, 10 Aug 2006 08:02:47 -0400 |
Forceful Browsing is related to Predictable Resource Location - http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml
Basically, it is when a client does not follow the proper/intended flow of a web app (by following web links) and instead alters the URL to try and directly access other resource locations based on educated guesses of the current URL composition.
Here is a personal example from a previous web assessment that I conducted. I logged into the customer portal with my test user credentials. I then went to veiw my bill from the previous month at the following URL - https://www.foo.com/Cust/cust_5.php/222557/20040216. By looking at the composition of the URL, I was able to recognize that the "222557" digit string was actually my customer number. I therefore attempted a forceful browsing request by then requesting the following URL - https://www.foo.com/Cust/cust_5.php/222558/20040216. Notice I changed the last number of the customer number from 7 to 8. I was then presented with the past bill for another customer.
Granted, this successful attack also combined a problem with the site's authorization mechanisms as it should have correlated my customer ID cookie values and disallowed my access to this page, however the key component was that I was able to get to this information due in part to forceful browsing.
Oftentimes, there are multiple threat/vulnerability vectors that are used together to exploit the system. Here are the 3 that were used for this attack -
1) Predictable Resource Location - I was able to decipher the URL composition. 2) Forceful Browsing - there was no weblink that the webapp created for me to follow to get to that new URL 3) Insufficient Authorization - although I had valid credentials, I was not authorized to see the data at that new URL location.
-- Ryan C. Barnett Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache
On 9 Aug 2006 14:26:59 -0000, indianwhitehathacker@yahoo.com <indianwhitehathacker@yahoo.com> wrote: > I was going through the OWASP Top Ten Guide and I came across these terms:- > > > 1. Parameter fuzzing > > 2. Forced browsing > > > What are these? Is forced browsing something like an attempt to access a resource that I am not supposed to access by putting the direct link with the necessary parameter values in a hope that may be in that page the authentication is broken? > > > Also, I read about fuzzers. Can someone throw light on what are fuzzers?
come on now, searching can give you all the answers...
but fuzzing is the process if sending in random data and seeing if the app crashes. the data be close to real data (a little fuzzy) or not close to real data at all (very fuzz).
'forced browsing' would, i guess, refer to the act of making the victims browser visit a page they didn't intend. done via some xss or even header injection into a badly santised 'redirect'.
but i'd think the OWASP Guide itself may document these things. maybe not. i'm sure the appropriate person will comment at the suggestion it doesn't, though :)
-- mic
------------------------------------------------------------------------- Sponsored by: Watchfire
Watchfire was recently named the worldwide market leader in Web application security assessment tools by both Gartner and IDC. Download a free trial of AppScan today and see why more customers choose AppScan then any other solution. Try it today!
https://www.watchfire.com/securearea/appscancamp.aspx?id=701500000008VnB --------------------------------------------------------------------------
------------------------------------------------------------------------- Sponsored by: Watchfire
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Comparison report on web app security scanners now translated to English, Holger.Peine |
|---|---|
| Next by Date: | RE: [WEB SECURITY] Ruby On Rails 1.1.5 Released to Address Critical Vulnerability, Caleb Sima |
| Previous by Thread: | Re: Parameter fuzzing and forced browsing, mikeiscool |
| Next by Thread: | Ruby On Rails 1.1.5 Released to Address Critical Vulnerability, bugtraq |
| Indexes: | [Date] [Thread] [Top] [All Lists] |