So as we move on, let's take a look at attack types and variance, starting with injection style. Now injection style attacks are one of the oldest and sadly still one of the most prevalent types. So let's cover what we mean by an injection. In this form of an attack, an attacker supplies an untrusted input to a program. In other words, we're injecting it into the program execution stream. Processed by interpreter as part of the commander query. And the result is a changed in the value injected into it alters the execution of that program. And several of the most common forms, cross-site scripting, which can result in spoofing arbitrary execution or defacement as well as others, OS command injection. This can result in full system compromise given the nature of the injection type.

A SQL command injection, which can bypass authentication, produce a denial of service, result in a breach, or full control of a target system. LDPA would again do authentication bypass and privilege escalation. Email header is great for doing spam relay and disclosure sensitive information. Any form of code injection could result in full system compromise. A simple sounding one, the carriage return line feed can result in a cross-site scripting attack, which can result in other things in a secondary way. And then the path through reversal can result in information disclosure and authentication bypass. We also have a family of encryption failures and these, obviously, can result in protection failures. We have various types of this beginning with hard-coded credentials, typically considered to be a very bad idea.

Now, hard-coded credentials work as coded every time they're executed, but they can be very difficult if not impossible to change. And crypto systems themselves have operational instructions for regular updates, regular key changes, and other sorts of rotational types exercises to keep them secure. But they can also be readily discovered by reverse engineering, a tactic that hackers frequently use. There can, of course, be the missing encryption for sensitive data. This is a well known approach that reflects the fact that sensitive information, of course, requires encryption for proper protection when at rest or in motion. And it is often lacking because the definition, however, leaves unanswered what information is sensitive.

This of course, places it on the shoulders of the developer or the user of the application and the application of the encryption to protect what they define as sensitive. Now, the use of questionable cryptographic components. This reflects a couple of different problems that are continuously arising. One being home-grown crypto. Now, home-grown crypto isn't approved or certified by anybody except those who choose to employ it. This, of course, means that it's not tested widely or officially, and what tends to happen is it fails when it's attacked by intense power due to the uninformed design that typically produces it. Likewise, older algorithms are often overwhelmed by attacks that may not have been envisioned when they were new such as we experience with DES and is replacement Triple DES.

Another problem with crypto is a flawed implementation can spoil very strong encryption that might otherwise work perfectly. This is what happened with WEP, the wired equivalent privacy and it negated the strength that is still inherent in the algorithm, RC4 that was at its core. So this reflect the need to design well and choose wisely for the components. Another cryptographic failure would be a download of a code or a code segment without any integrity validation. Now, this should be done to make sure that the code is authentic and unmodified, and that there are no unwanted malware attachments or embedded code segments. Using unsalted hashes. This adds trailing values to data strings such as passwords and by doing so increases both the length and the randomness of the product. The use of an unsalted hash makes breaking data-protecting passwords far easier.