Difference between revisions of "Web Site Security"
From MgmtWiki
(→Context) |
(→Windows Specific Guidance) |
||
| (12 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
==Context== | ==Context== | ||
| − | * There are a number of web platforms, more it seems every day. | + | * 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. | * 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. | ||
| + | * [https://www.akamai.com/us/en/resources/content-delivery.jsp 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
==Problems== | ==Problems== | ||
| − | * | + | * 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. |
| − | + | * | |
| − | |||
==Solutions== | ==Solutions== | ||
| Line 22: | Line 21: | ||
* 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. | * 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. | * 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 Rules=== | ||
| + | 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. | ||
| + | ===Principal User Accounts=== | ||
| + | Typically web sites are not run as sign-in user accounts, but on virtual or service accounts with limited access permissions. | ||
| + | |||
| + | ===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] | ||
| + | * [https://blog.netwrix.com/2018/04/18/how-to-manage-file-system-acls-with-powershell-scripts/#How%20to%20disable%20and%20enable%20permission%20inheritance using powershell to set file permissions] | ||
| + | |||
| + | ===Linux Specific Guidance=== | ||
==References== | ==References== | ||
Revision as of 22:10, 21 July 2020
Contents
Full Title and Meme
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.
Context
- 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.
Problems
- 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.
Solutions
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 Rules
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.
Principal User Accounts
Typically web sites are not run as sign-in user accounts, but on virtual or service accounts with limited access permissions.
Windows Specific Guidance
- For more details see the wiki page IIS Security Practices.
- File Access rules
- Principle user accounts
- using powershell to set file permissions
Linux Specific Guidance
References
Organizational Support
- 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.
