7 hours 6 minutes
Hey, everyone, welcome back to the course. So in this video, we're to talk about some Web attack countermeasures, so we'll talk about it in different ways. We could defend against Web services attacks as well. Some things we could do to defend against Web application attacks.
So for Web services attacks, we can use multiple security credentials. So things like Samuel assert ations ws Security X 509 certifications, etcetera.
We can configure W S D L access control permissions. So, basically, to grant or deny access to any type of W S d l based soap messages, we could configure our firewalls and I D s and I ps systems to look for Web services Anomalies look for signatures that are known to detect those. We also have them
filter improper soaper xml syntax for us.
Some countermeasures for command injection attacks. So doing things like input validation. So again, we talked about sequel injection attacks. That's one form of command injection attacks
and just following that input to make sure that this is a legitimate query to the back end database
escaping any dangerous character So again, making sure that the attacker can't actually use
specific characters in a query that might allow them to pull information from the database
using language specific libraries. Um, that can help avoid problems because of that are due to shell commands setting specific sequel query parameters. So making sure that if it's outside the parameter, the command will not actually run on, then treating the parameters as data and not execute herbal content. So just making sure that
theater hacker can't actually execute whatever commands they want to.
This is just the system is just basically saying, Oh, this is just data This is just data were reviewing its not an execute herbal code cross site scripting attacks so we can make sure that we validate headers, cookies, query strings, form fields, hidden fields. So basically just validating all the the parameters against
our normal specifications,
we can also implement things like a Web application firewall. So the laugh to block execution of Melissa scripts. We can make sure that we're in encoding our input and output and also filter the medic characters in the input.
We can convert non alphanumeric characters to HTML character entities before displaying the user input in in things like search engines or forums
we could sign our scripts. Just make sure that these air actually signed with public or private and your private keys that actually make sure that the script is from unauthenticated source for Dido's and denial of service attacks. We could do things like figuring the firewall to deny that ICMP so that ping traffic
we could secure remote administration or just disable it all together. If we don't need it on our Web servers, we can also perform things like connectivity testing. We could prevent unnecessary functions on the on the Web server, so make sure we disable things like gets or string copy. We could also perform things like
input validation. So making sure that we do have specific parameters in place to help protect against those command injection attacks
for things like cross site request forgery, we could do things like making sure we log off immediately after the Web application is used and clearing our browser history. We could also make sure that our browser in different websites we visit are not saving our log in credentials,
and we can also check the http refer header when we're processing a post and then ignoring U R L parameters
for broken authentication and such a management, we can make sure we do things like using SSL for authenticated parts of the application. We can verify user identities and credentials and see if they're stored in a hashed form,
and then just make sure we never submit session data as part of our get or post responses for directory traverse. A. We could make sure that we define access rights to protected areas of the website. We could make sure we're applying things like hot fixes or checks that prevent exploitation of vulnerabilities. Eso, for example, things like Unicode
that might be able to affect directory. Trevor Traverse ALS
a. Zwelling as making sure that we update our Web servers with the proper patching again. Of course, we test the patches before we deploy them to production, but making sure that we've got a good patch management system in place, cookie poisoning or session poisoning. So making sure that we don't store plain text or weekly encrypted passwords or other credentials inside of a cookie,
making sure that we time out those cookies so the attacker can't use it
for a session later on, making sure that the authentication credentials in the cookie are associated with a specific I P address and making sure that's a valid i p address on, then also making sure that there's a log of function Azaz well
and security Miss Configuration. So configuring the Web server to turn off things like unused services, making sure we set up proper roles permission. So again, using things like least privilege
and making sure that we disable any default accounts as well as changing any default credentials that might be out there as and also making sure that we scanned the Web server for any vulnerabilities, the latest vulnerabilities and then making sure again, going back to the Patch Management, making sure we have an appropriate patch procedure in place.
So this a quick, quick question for you. Defending against Common command injection attacks include Which of the following is a validating cookies? Is a using language specific libraries? Or is it configuring? W S D l access control permissions?
All right, so if you guessed using language specific libraries, you are correct.
So in this video, we just briefly covered some different ways you can defend against Web services attacks as well as different ways to defend against Web application attacks