Let us conclude our Web application section by having a look on the Web application countermeasures
that how you should prevent such attacks.
Let us see the force that is broken authentication and session management for this use SSL that is sigatoka
clear for authenticated, a part of the application verify whether all the user's identities and credentials
are stored in hashed form that is used hashing and cryptography.
I never submit session data is a part of it or both requests never do that.
The next is XML entity that is a word processing XML input containing a reference to the external entity.
Then XML unmarred should be configured securely past the document with the securely configured parser.
Next, sensitive data exposure do not create or use weak cryptographic algorithms as they may result
in sensitive data exposure, then generate encryption keys off-line and store them securely and ensure
that the encrypted data are stored on the disk is not easy to decrypt and therefore brute force attacks
won't work in this case.
The next is broken access control that is busy now perform access control checks before redirecting
the authorized user to request a resource check whether it is only legitimate user who is trying to
access the user requested resource avoid using insecure items to prevent a tiger from getting it, then
provides session timeout mechanism.
If a user is not active for, let's say, 30 to 40 seconds, you can adjust a timeout decision and log
out the user forcefully and then limit the permissions to authorized users from misuse.
The next is how you can prevent a scale injection attacks limit the length of the user input, as we
have seen, that if you change the input from 10 to 15 or 100 and then only user can input a string
or a big function, but if you limit that only or as attacks can be prevented, then use custom error
messages, do not disclose any information through errors, just give an error that that's a error that
you do not have to display anything else, then monitor database traffic using ideas, firewalls and
other application firewalls, disable commands like expectation.
If you want to read more about this, you can always go to the books that you have attached for Web
application resources, then isolate a database server and a web server also.
And the next is filing a tax that is file upload, strongly worded user input.
Consider implementing a jail route, then disable a love.
You are left open and allow your URL in BHP, not Ironi.
We have seen this while installing the Linux in time when the of application.
If you do not recall, please go to that lecture in Section two, setting up the penetration testing
lab, then ensure that all files and streams functions are carefully vetted.
Do not allow any random file to be inputted.
The next is command injection flows, perform again input validation, escape dangerous characters.
Use language specific libraries that avoid problems due to shell commands, perform input and output
encoding, and use a safe API which avoids the use of interpretor entirely.
Then the next is using components with known vulnerabilities.
How you can avoid that you can avoid by regularly checking the versions of both client side and so rules
or components and their dependencies then continuously monitor sources like National Vulnerability Database
for vulnerabilities in your components, apply security patches, regularly scan the components with
security scanners, frequently enforce security policies and best practices for component use.
And the second last is cross site request forgery attack here log of immediately after using our application
and clear the history.
We have seen that if you log off and if you delete all the data after the user has created the browser,
attackers cannot use the site of attack.
Then do not allow your browser and websites to save login details, which is a bad practice, and also
check the header of processing a post.
Another type of request.
And the last and important is kookier parameter time, putting the not stored plaintext or weakly encrypted
passwords in a cookie that is not allowed and that is always a bad practice.
Implement cookies.
Timeout.
Let's see.
After four to five days, if a user hasn't visited the website, you can delete the cookie and whenever
a user tries to log in again, you can ask for more security questions to ensure that the same user
is logging and finally make logged functions available.
Insist the user to log out before closing a browser and using all this with the application attacks
can be prevented.
Uh, so in the next section onwards we are going to start the DENIAL-OF-SERVICE section that is the
DOS.