Database Reference
In-Depth Information
Inappropriate cleaning
The vulnerability code for inappropriate cleaning is EH06 .
As you can see from the preceding code, we have CleanUpRoutines() in the fi-
nally block. This is a mandatory part for any final block—all connections must be
closed, file pointer released, threads unlocked, and memory cleaned from the loop-related
variables. This is highly important as some attacks are not only aimed at revealing tech-
nical implementation details but also at depleting the service resources.
Handling dissimilar exceptions in the same block
The vulnerability code for handling dissimilar exceptions in the same block is EH07 .
This situation is quite close to the one described for vulnerability with code EH02 and can
also be presented by using the same exception handler for differed named exceptions. An
indiscriminate handler will not only open the door to the mishandling of complex situ-
ations simulated by an attacker, but also will leave an unclear trace record in the system's
logs, blinding the response/ops team.
Authentication and authorization vulnerabilities
Here we mostly talk about API authentication (System-to-System) and not just about hu-
man and web page interactions (although it's also based on SOAP and REST services,
serving direct and brokered authentication). In this case, arguably, you can assume the
main authentication weakness of all time—the password strength can be finally tamed as
the API is not affected by typical human factors, that is, the ability to remember pass-
words (or leaving yellow sticky notes on the monitor). Indeed, just from a password
strength calculator (you will find a lot of them on the Web), we can see that a four-charac-
ter password, which is common for humans, can be brute forced in a couple of minutes,
while a 20-character API key will take ages (with adequate OS (Linux/Unix/Windows)
file protection in place, of course).
Well, our optimism should be very cautious about that though. Not too long ago, we were
able to use Amazon S3 and EC2 cloud services (actually, AMIs with all our assets) to log
in with our regular Amazon shopping account. So naturally, as mentioned earlier, using
signature-wrapping (stripping) and cross-site scripting (XSS) attacks, pentesters were able
to compromise these Shopping and EC2 credentials and gain total control over the vic-
tim's account with virtual machines containing stored code and data. Should we mention
the victim's shopping cart? Should we also mention that EC2 is probably the most popular
sandbox for developers from several leading companies?
Search WWH ::




Custom Search