Element Duplication
I read http://www.soapui.org/SOAP-and-WSDL/web-service-hacking/Tip-6-Element-Duplication.html on your website the tip 6 about Element duplication. Just curious to hear how this is a vulnerabilit...
Forum Discussion
Hello,
Sadly it is quite vague , though overall a decently nice article to read. My presumption of what the end user would be looking for there would be error messages that give information or details about the server, database and to triple check that an array/list is not being accepted. The majority of White Hat Testing revolves around limited access to information about the specific details of the server/database.
To add another technique that I regularly deploy to the scenario with White Hatting web services that will sort of fall under step 9's "boom" method.
Find a service that accepts arrays/lists. Anything that can be repeated. Repeat it 100000 times, watch as the system goes boom. Using expected data that will not error will typically cause this to be even more resources intensive since a lot of data verification steps are within code portions and you might want to focus onto the DB read/writes. Using unexpected data can be useful to ensure that when the system finds a fault it just fails where it is instead of attempting to continue on which opens up the ability for a random person who knows nothing about your system to take it down as they please.
Sadly it is quite vague , though overall a decently nice article to read. My presumption of what the end user would be looking for there would be error messages that give information or details about the server, database and to triple check that an array/list is not being accepted. The majority of White Hat Testing revolves around limited access to information about the specific details of the server/database.
To add another technique that I regularly deploy to the scenario with White Hatting web services that will sort of fall under step 9's "boom" method.
Find a service that accepts arrays/lists. Anything that can be repeated. Repeat it 100000 times, watch as the system goes boom. Using expected data that will not error will typically cause this to be even more resources intensive since a lot of data verification steps are within code portions and you might want to focus onto the DB read/writes. Using unexpected data can be useful to ensure that when the system finds a fault it just fails where it is instead of attempting to continue on which opens up the ability for a random person who knows nothing about your system to take it down as they please.