From 29283389c8412ecf7bd09560aee51569103a01ee Mon Sep 17 00:00:00 2001 From: William Sandner Date: Sun, 1 Aug 2021 13:06:38 +0200 Subject: [PATCH] Clear linter warnings --- Design-Security.md | 42 +++++++++++++++--------------------------- 1 file changed, 15 insertions(+), 27 deletions(-) diff --git a/Design-Security.md b/Design-Security.md index a670742..14853f5 100644 --- a/Design-Security.md +++ b/Design-Security.md @@ -1,7 +1,10 @@ + ##### Project + ::PROJECT-NAME ##### Internal Release Number + ::X.Y.Z ##### Related Documents @@ -14,8 +17,7 @@ ### Overview -*TODO: Answer the questions below to help you design needed security -features. Some example text is provided. Add or delete text as needed.* +*TODO: Answer the questions below to help you design needed security features. Some example text is provided. Add or delete text as needed.* #### What are the most important facts that a developer should know about the security of this system? @@ -30,7 +32,6 @@ features. Some example text is provided. Add or delete text as needed.* ### Security Mechanisms - #### What physical security mechanisms will be used? - ::Servers will be kept in a locked room with door code known only @@ -94,19 +95,15 @@ features. Some example text is provided. Add or delete text as needed.* are: - ::Guest: Visitor to the site is not logged in, no permissions to change anything - - ::Guest: Visitor to the site is not logged in, can post - messages anonymously - - ::RegisteredUser: User is logged in, has permissions for X, Y, - and Z - - ::Administrator: Permission to change anything, even on behalf - of other regular users + - ::Guest: Visitor to the site is not logged in, can post messages anonymously + - ::RegisteredUser: User is logged in, has permissions for X, Y, and Z + - ::Administrator: Permission to change anything, even on behalf of other regular users - ::Each action (information display or change) requires that the user has a role with proper permissions -- ::Compromised or abused accounts can be quickly disabled - by administrators. > -- ::Administrators can review user > permissions -- ::Administrators can audit all a > ccesses and changes -- ::All communications with the us > er are encrypted (e.g., SSL) +- ::Compromised or abused accounts can be quickly disabled by administrators. +- ::Administrators can review user permissions +- ::Administrators can audit all accesses and changes +- ::All communications with the user are encrypted (e.g., SSL) - ::Some communications with the user (e.g., the username and password) are encrypted (e.g., SSL) - ::Sessions are tied to a particular client IP-address so that @@ -117,19 +114,10 @@ features. Some example text is provided. Add or delete text as needed.* where it can still be reviewed by administrators. - ::Sensitive data, such as credit card numbers, are processed but not retained in any database or file -- ::The data access layer will be responsible for preventing SQL - injection attacks (i.e., hackers attempting to enter SQL - statements through application UI fields). -- ::The data access layer will allow read-only connections, which - will be used for most requests, as well as write connections for - requests that update the database. -- ::The HTML generation layer will be responsible for preventing - cross-site-scripting (XSS) attacks. -- ::The application will prevent CSRF attacks. It will do this by - performing updates to the database only after a POST, and - checking that the referring page was served by the system for - every POST. Browsers that do not report HTTP-Referrer will not - be supported. +- ::The data access layer will be responsible for preventing SQL injection attacks (i.e., hackers attempting to enter SQL statements through application UI fields). +- ::The data access layer will allow read-only connections, which will be used for most requests, as well as write connections for requests that update the database. +- ::The HTML generation layer will be responsible for preventing cross-site-scripting (XSS) attacks. +- ::The application will prevent Cross-Site Request Forgery (CSRF) attacks. It will do this by performing updates to the database only after a POST, and checking that the referring page was served by the system for every POST. Browsers that do not report HTTP-Referrer will not be supported. ### Security Checklist