Completely unknown to me, as I was testing, my spider was running. Now the account I was testing with was an account of elevated prvileges. The developers had decided it would make sense to harcode the URI, the stored procedure along with stored procedures parameters (option included) into the page via an HREF. The link looked something like www.example.com/disable_profiles?disable=true........which made for an interesting next few days (this was a production app). I admit I did not specifically ask the development team if functionality like this was hardcoded into the page via HREF.
Interesting to note, it actually took a while for some folks to understand that a pop-up, via JavaScript, warning "this will disable all users profiles" may not actually be 1) visible to an intercepting proxy or 2) be an effective enough deterrent!
Moral of the story, I now ask my customers if they code functionality like this into the pages or any other potentially disruptive functionality I may need to know about.
To exclude this type of functionality from being used by tools such as Spider and Scanner you should perform the following. Navigate to Target > Scope.
Okay, now add your exclusion. You can choose the 'any' protocol option but in my case I know two things. Only port 80 is open and we will be using http. You will see (where highlighted) we've added the protocol [http] the host [www.example.com] the port [80] and finally the actual name of the page we dont want to touch with a ten foot pole [disable_profiles].
Okay, simple enough stuff but in my case a potential '@ss-saver'.
Happy SAFE Hacking!
No comments:
Post a Comment