Web Application Security
Download as PPTX, PDF1 like464 views
This document discusses various strategies for securing web applications, including: implementing content security policies, anti-cross-site request forgery measures, secure credential storage, security frameworks, and disabling password autocomplete. It notes that retrofitting security measures can be difficult after a site has been developed, as it may require changes across many files and features. The document recommends building security best practices into websites from the start.
Web Application Security
- 1. Created By Cygnis Media http://www.cygnismedia.com/
- 2. Web application security is a branch of Information Security that deals specifically with security of websites, web applications and web services. At a high level, Web application security draws on the principles of application security but applies them specifically to Internet and Web systems. Typically web applications are developed using programming languages such as PHP, Java EE, Java, Python, Ruby, ASP.NET, C#, VB.NET or Classic ASP.
- 3. Content-Security-Policy X-Frame-Options Anti-CSRF cryptographic nonces on all secure functions DAL (data/database access layer) Unwritable file system Forensically secure logging Secure credential/passwd/secret questions and answers storage Security frameworks autocomplete="off" and strong passwords
- 4. We suggest you apply this with the notifying switched on, so that you can see what's splitting as your devs will work on it. It can be incredibly hard to develop into your website retroactively, because it usually includes either including so many whitelists that it's essentially useless, or having to go carefully through your website to make a large stock, expecting that you don't skip anything along the way. There is now a bookmarklet to help as well.
- 5. (one time tokens tied to user sessions) into each type and verifying that to make sure that your site can't be compelled to execute activities. This can be a huge pain to retrofit because it means in contact with a data source or distributed storage on every hit — in addition to the rule that needs to be placed into each web page with a type and following operate to confirm the nonce.
- 6. We suggest building nonces (one time tokens tied to user sessions) into each type and verifying that to make sure that your site can't be compelled to execute activities. This can be a large pain to retrofit because it means in contact with a data source or distributed storage on every hit in addition to the rule that needs to be placed into each web page with a type and following operate to confirm the nonce.
- 7. DALs help to avoid SQLinjection. Few organizations know about them or use them properly, but by front side finishing all data source with an abstraction part many types of SQL hypodermic injection basically don't succeed because they are not properly established. DALs can be costly and incredibly complicated to retrofit because every individual data source contact needs adjustment and interpolation at the DAL part.
- 8. Making the website rule and webserver configs on the computer file program unwritable by the web customer is a large protection benefits post- compromise. Almost no sites take this precautionary activity but it makes many types of exploitation nearly difficult. Retrofitting this is difficult to do later because plenty of things usually depend on local computer file program creates as the site advances over time, even though this type of style can be incredibly poor.
- 9. Records that are sent off-host or are created otherwise not reachable by the web customer help avoid overwriting the computer file program, regional consist of strikes, eliminating the assailant's paths from the logs and so on. It's challenging to describe how useful it is to have untampered logs until after it's too delayed. It is challenging to retrofit because it usually needs creating different signing facilities and developing some way to duplicate or instantly transportation the logs.
- 10. How many sites have we seen affected and all of the information is taken? In most situations it is either plaintext or badly hashed with an outdated hashing criteria, like MD5. Supposing that everything in the information source is duplicated off, the enemy still shouldn't have accessibility anything without investing loads of sources to break individual series. This can be extremely complicated to retrofit because many site features depend on current information source styles and the associated organized information.
- 11. Collections for managing and sanitising or rejecting customer feedback (XSS, SQLi, Control hypodermic injection, etc...) significantly enhance your capability to proactively secure yourself when used consistently across the website. Collections like this usually need modifying many website features, and these frameworks therefore contact almost every feedback, so it can be a headache to develop after the fact.
- 12. To secure your website from incredible power and from the latest allergy of protection problems in autocomplete, it is a wise decision to apply both of these. If your customers think the web browser will keep in mind their protection passwords for them it's going to be a headache when you convert autocomplete="off" later. If you convert it off beginning, they'll select poor protection passwords. So you really need both at the same time. You don't want the assistance expenses of all of your customers contacting you trying to determine how to get returning into their consideration.
- 13. Created By Cygnis Media: http://www.cygnismedia.com/Data Collect: itproportal.com