Difference between revisions of "Web Site Security"

Revision as of 22:10, 21 July 2020

This page is about the means to make sure that your web site is as secure as it can be.

For information about the user perspective see the wiki page User Trust of a Web Site.

There are a number of web platforms, more it seems every day, like Apache, ASP.NET, JSP etc.
But there is also a large commonality, like the security protocol HTTPS which is well over 90% penetration of all sites, mostly due to Google's insistence.
Nearly all of the web platforms run on Windows or Linux, typically hosted by one of the major providers, like Amazon or Microsoft, which have global reach.
Cloud Flare and others provide security support at the edge, like protection from Denial of Service (DoS) attacks.
Akamai and many other provider content delivery platforms.
This page will focus on the parts that are typically under control of the web app architectural and development teams.

Businesses hire programmers that can deliver business solutions on the web. Security of the web site is never the first consideration, and there is plenty of evidence that it isn't fully funded until after the site has gone live and been attacked.

These are proposed on 2019-05-08 for a future release:

The Web Site exposes its name in a manner that allows the user to make a meaningful trust decision. See the page on Trusted Identifier and Web Site Identity for details.
Most browsers come with a feature that will evaluate any file downloaded to a computer based on a set of constantly updated filters installed in the cloud.

File system access goes back to the original studies the the Air Force that reading and writing need to be controlled so that:

Sensitive data is protected from release to an area of lower sensitivity. So data can be written only from a lower sensitive to a higher.
Executable code is protected from running with more privileges than where it is approved. So execrable can only be written from a higher to a lower level.

It is common for access rules to combine execute permissions with read permissions. This violates good security practice. Here are some good rules.

The web front end executable should be considered to have very low security as it can be complex and vulnerable to attack. No ability to write executable code can be permitted. Since it is not always clear what code is executable, the file system where data is written should not allow execution of code from the same areas.

Typically web sites are not run as sign-in user accounts, but on virtual or service accounts with limited access permissions.

The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of web site software.
ISACs are member-driven organizations, delivering all-hazards threat and mitigation information to asset owners and operators.

@@ Line 31: / Line 31: @@
 ===Windows Specific Guidance===
+* For more details see the wiki page [[IIS Security Practices]].
 * [https://www.google.com/search?q=.net+filesystemaccessrule&rlz=1C5CHFA_enUS882US882&oq=net+FileSystemAccess&aqs=chrome.1.69i57j0l7.26191j1j7 File Access rules]
 * [https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities Principle user accounts]