Difference between revisions of "Security tests of bxp and False Positives"
From All n One's bxp software Wixi
Philip Lacey (talk | contribs) |
|||
| Line 1: | Line 1: | ||
| − | = Overview = | + | =Overview= |
| − | |||
| − | |||
bxp is a secure platform and the security of All n One is paramount to All n One operations. | bxp is a secure platform and the security of All n One is paramount to All n One operations. | ||
| − | Security requirements change all the time. | + | Security requirements change all the time. As new security weaknesses are found constantly bxp is constantly adapting to those challenges. |
| − | |||
| − | |||
| + | We often receive security testing and testing results. During these tests, results can appear which are not issues but are flagged as issues. This is called a false positive. Common tests and their results and already mitigated / understood and managed issues. These issues are listed here with explanations and mitigations | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | =False Positives= | ||
| + | ==Issue : XSS (Cross Site Scripting) Injection== | ||
''' Presents as ''' | ''' Presents as ''' | ||
| − | The usual test for SQL injection is to include alert(1); or equivalent JavaScript into the system. | + | The usual test for SQL injection is to include alert(1); or equivalent JavaScript into the system. The system shouldn't allow this. |
| Line 27: | Line 21: | ||
| − | bxp actually provides facility for a client to customise the platform with custom JavaScript. | + | bxp actually provides facility for a client to customise the platform with custom JavaScript. The primary areas where this happens are: |
| + | |||
* Form Management : Form settings | * Form Management : Form settings | ||
* Form Management : Outcomes | * Form Management : Outcomes | ||
| Line 34: | Line 29: | ||
| − | Through UAM (User Access Management), [[UAM_-_User_Access_Management]] and the System Access Management module [[Module_-_System_Access_Management]] access to different aspects of the system are controlled. | + | Through UAM (User Access Management), [[UAM_-_User_Access_Management]] and the System Access Management module [[Module_-_System_Access_Management]] access to different aspects of the system are controlled. User secure access should be controlled. [[Function_Vs._Content]] Regular client auditing of logins and system usage then provide the control of who is accessing what and when. [[Security_-_Start_Here#System_Review_tools]] A bxp client is not forced to use UAM but it is highly recommended. |
| − | |||
| − | |||
| − | |||
| + | ==Issue : Privilege Escalation== | ||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 50: | Line 43: | ||
| − | When providing a test user it is important to understand the scope of the test user. | + | When providing a test user it is important to understand the scope of the test user. The test user for Penetration testing can be set to an extremely limited user type account rather than an administrative level account. |
| − | |||
| − | |||
| + | The System Access Management module provides functional and content access. If a user has scope to be able to make changes in this module then they are effectively Administrators. Through UAM (User Access Management), [[UAM_-_User_Access_Management]] and the System Access Management module [[Module_-_System_Access_Management]] access to different aspects of the system are controlled. A bxp client is not forced to use UAM but it is highly recommended. | ||
| − | |||
| − | |||
| + | ==Issue : Session Cookie life== | ||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 69: | Line 60: | ||
| − | bxp provides a dedicated log out process. | + | bxp provides a dedicated log out process. If the logout process is used then the cookies and credentials are removed from the system requiring the user to log in again. |
| − | == Issue : Autocomplete field for username and password entry == | + | ==Issue : Autocomplete field for username and password entry== |
| − | |||
| − | |||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 91: | Line 80: | ||
| − | The solution to get compliance is to add JavaScript to add the attribute to the input tag. | + | The solution to get compliance is to add JavaScript to add the attribute to the input tag. This is implemented on bxp |
| − | |||
| − | |||
| − | |||
| + | ==Issue : Error messages with too much data== | ||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 107: | Line 94: | ||
| − | The hamster errors are provided as is to facilitate accurate trouble shooting with minimum issues. | + | The hamster errors are provided as is to facilitate accurate trouble shooting with minimum issues. The detailed hamster errors are only generated for valid logged in users. White hamsters have limited information and are the only hamster available outside of log in. |
| − | |||
| − | |||
| + | ==Issue : Cookie valid duration== | ||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 124: | Line 110: | ||
| − | Cookies in bxp have a window of 14 days. | + | Cookies in bxp have a window of 14 days. If a smaller window of timeout needs to be controlled then bxp provides an inactivity management solution [[Security_-_Force_inactive_logout]] |
| Line 131: | Line 117: | ||
| − | == Issue : No account lockout == | + | ==Issue : No account lockout== |
| − | |||
| − | |||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 143: | Line 127: | ||
| − | A lockout engine is built into bxp which is configurable by client. | + | A lockout engine is built into bxp which is configurable by client. This option is specified by the client on system setup [[CC-2-1_Security_and_Custom_Interface_configuration#Lockouts_and_Options]] |
| − | == Issue : Weak passwords allowed == | + | ==Issue : Weak passwords allowed== |
| − | |||
| − | |||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 166: | Line 148: | ||
| − | == Issue : Caching responses == | + | ==Issue : Caching responses== |
| − | |||
| − | |||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 186: | Line 166: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| − | Different browsers implement and interpret these instructions differently. | + | Different browsers implement and interpret these instructions differently. IE5 through IE8 do not work well with pragma no-store. no-cache therefore is the compromise for backwards compatability. |
[https://stackoverflow.com/questions/866822/why-both-no-cache-and-no-store-should-be-used-in-http-response] | [https://stackoverflow.com/questions/866822/why-both-no-cache-and-no-store-should-be-used-in-http-response] | ||
| − | == Issue : TLS V1.0 available == | + | ==Issue : TLS V1.0 available== |
| − | |||
| − | |||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 203: | Line 181: | ||
| − | For backwards compatibility of TLS and earlier browsers which are end of life, TLS 1.0 is still available but only through negotiation as stronger encryptions are presented by default. | + | For backwards compatibility of TLS and earlier browsers which are end of life, TLS 1.0 is still available but only through negotiation as stronger encryptions are presented by default. [[What_browsers_does_bxp_work_on%3F]] |
| − | == Issue : Reflective Cross-Site Scripting (XSS) == | + | ==Issue : Reflective Cross-Site Scripting (XSS)== |
| − | |||
| − | |||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 225: | Line 201: | ||
| − | == Issue : Sensitive Information Exposure - Server Response Headers == | + | ==Issue : Sensitive Information Exposure - Server Response Headers== |
| − | |||
| − | |||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 237: | Line 211: | ||
| − | bxp as part of it's compliance and regulation management provides a number of details about it's service publicly which mitigate the sensitivity of cookie and header information. | + | bxp as part of it's compliance and regulation management provides a number of details about it's service publicly which mitigate the sensitivity of cookie and header information. [[The_bxp_Infrastructure]] |
| − | The hamster engine of bxp relies on information from a validly logged in user to provide technical support as to the nature of the issue that's occurred to allow a client to correct their own errors. | + | The hamster engine of bxp relies on information from a validly logged in user to provide technical support as to the nature of the issue that's occurred to allow a client to correct their own errors. The modules of MetaData and KeyStats are the two primary examples of where this matters most. [[Meet_the_Hamsters]] |
| − | == Issue : Unprotected file upload == | + | ==Issue : Unprotected file upload== |
| − | |||
| − | |||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 256: | Line 228: | ||
| − | bxp facilitates clients with sufficient permissions the ability to add .js files to the engine for their own operations. | + | bxp facilitates clients with sufficient permissions the ability to add .js files to the engine for their own operations. eCourse pages facilitate a wider variety of supported materials. On all uploaders there are mime type approved lists. AntiVirus solutions monitor in real time all uploads with eicar being used extensively to monitor file upload points. |
All upload points are limited and auditable. | All upload points are limited and auditable. | ||
| − | |||
| − | |||
| + | ==Issue : httpOnly not applied== | ||
''' Presents as ''' | ''' Presents as ''' | ||
| Line 274: | Line 245: | ||
| − | Due to the implementation of the httpOnly flag using IIS Response.AddHeader "Set-Cookie" implementation to set a cookie flag at the end of the page, results in some testing software not properly detecting that the flag has been set. | + | Due to the implementation of the httpOnly flag using IIS Response.AddHeader "Set-Cookie" implementation to set a cookie flag at the end of the page, results in some testing software not properly detecting that the flag has been set. As bxp has to provide an HTTP implementation for backwards compatibility the httpOnly flag cannot be universally set by IIS and is implemented therefore in this fashion. |
| + | |||
| + | |||
| + | ==Issue : Cipher Suite Updates== | ||
| + | '''Presents as''' | ||
| + | |||
| + | |||
| + | Bxp using legacy ciphers that do not support Forward secrecy | ||
| + | |||
| + | '''Mitigation''' | ||
| + | |||
| + | |||
| + | Forward Secrecy : We are reviewing our weblog reports to see what browsers / Operating systems are being used within bxp. This will allow us to create a more updated cipher suite listing. In some instances we may need to keep certain ciphers alive to support clients using legacy systems. With regard to forward secrecy we are currently testing the following cipher suite: | ||
| + | |||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384, | ||
| + | |||
| + | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256, | ||
| + | |||
| + | TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, | ||
| + | |||
| + | TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, | ||
| + | |||
| + | TLS_DHE_DSS_WITH_AES_256_CBC_SHA, | ||
| + | |||
| + | TLS_DHE_DSS_WITH_AES_128_CBC_SHA, | ||
[[Category:Topic:Security]] | [[Category:Topic:Security]] | ||
Latest revision as of 16:06, 24 July 2017
Contents
- 1 Overview
- 2 False Positives
- 2.1 Issue : XSS (Cross Site Scripting) Injection
- 2.2 Issue : Privilege Escalation
- 2.3 Issue : Session Cookie life
- 2.4 Issue : Autocomplete field for username and password entry
- 2.5 Issue : Error messages with too much data
- 2.6 Issue : Cookie valid duration
- 2.7 Issue : No account lockout
- 2.8 Issue : Weak passwords allowed
- 2.9 Issue : Caching responses
- 2.10 Issue : TLS V1.0 available
- 2.11 Issue : Reflective Cross-Site Scripting (XSS)
- 2.12 Issue : Sensitive Information Exposure - Server Response Headers
- 2.13 Issue : Unprotected file upload
- 2.14 Issue : httpOnly not applied
- 2.15 Issue : Cipher Suite Updates
1 Overview
bxp is a secure platform and the security of All n One is paramount to All n One operations.
Security requirements change all the time. As new security weaknesses are found constantly bxp is constantly adapting to those challenges.
We often receive security testing and testing results. During these tests, results can appear which are not issues but are flagged as issues. This is called a false positive. Common tests and their results and already mitigated / understood and managed issues. These issues are listed here with explanations and mitigations
2 False Positives
2.1 Issue : XSS (Cross Site Scripting) Injection
Presents as
The usual test for SQL injection is to include alert(1); or equivalent JavaScript into the system. The system shouldn't allow this.
Mitigation
bxp actually provides facility for a client to customise the platform with custom JavaScript. The primary areas where this happens are:
- Form Management : Form settings
- Form Management : Outcomes
- eCourse : Asset : Creation and application system wide
- System Access Management : System Management : System Settings
Through UAM (User Access Management), UAM_-_User_Access_Management and the System Access Management module Module_-_System_Access_Management access to different aspects of the system are controlled. User secure access should be controlled. Function_Vs._Content Regular client auditing of logins and system usage then provide the control of who is accessing what and when. Security_-_Start_Here#System_Review_tools A bxp client is not forced to use UAM but it is highly recommended.
2.2 Issue : Privilege Escalation
Presents as
Normal level users can access secure areas.
Mitigation
When providing a test user it is important to understand the scope of the test user. The test user for Penetration testing can be set to an extremely limited user type account rather than an administrative level account.
The System Access Management module provides functional and content access. If a user has scope to be able to make changes in this module then they are effectively Administrators. Through UAM (User Access Management), UAM_-_User_Access_Management and the System Access Management module Module_-_System_Access_Management access to different aspects of the system are controlled. A bxp client is not forced to use UAM but it is highly recommended.
2.3 Issue : Session Cookie life
Presents as
Sessions are not expired in a timely fashion
Mitigation
bxp provides a dedicated log out process. If the logout process is used then the cookies and credentials are removed from the system requiring the user to log in again.
2.4 Issue : Autocomplete field for username and password entry
Presents as
Autocomplete should be added to the username and password log in fields.
Mitigation
Autocomplete is not a valid HTML 4.0 strict or XHTML 1.0 valid attribute and is widely discussed on the Internet [1]
bxp is XHTML 1.0 strict compliant [Security_-_Start_Here#W3C_XHTML_Compliance]
The solution to get compliance is to add JavaScript to add the attribute to the input tag. This is implemented on bxp
2.5 Issue : Error messages with too much data
Presents as
Hamster errors present too much data which could provide attackers with unnecessary data.
Mitigation
The hamster errors are provided as is to facilitate accurate trouble shooting with minimum issues. The detailed hamster errors are only generated for valid logged in users. White hamsters have limited information and are the only hamster available outside of log in.
2.6 Issue : Cookie valid duration
Presents as
Cookies have a long window of activity increasing session hijacking possibilities
Mitigation
Cookies in bxp have a window of 14 days. If a smaller window of timeout needs to be controlled then bxp provides an inactivity management solution Security_-_Force_inactive_logout
Whilst it is possible to set smaller and smaller windows, bxp user convenience is also a consideration.
2.7 Issue : No account lockout
Presents as
Lockout policy not applied.
Mitigation
A lockout engine is built into bxp which is configurable by client. This option is specified by the client on system setup CC-2-1_Security_and_Custom_Interface_configuration#Lockouts_and_Options
2.8 Issue : Weak passwords allowed
Presents as
Weak passwords allowed as valid
Mitigation
A client can specify a minimum strength password allowed as part of their configuration CC-2-1_Security_and_Custom_Interface_configuration#Password_cycling
bxp has a detailed password strength reporting suite to facilitate management of this aspect of security Security_-_Password_Strength_Report
2.9 Issue : Caching responses
Presents as
When a user clicks back in a browser, after a successful log out, data is still visible from the browser's cache.
Mitigation
On all pages in bxp the following is implemented
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="pragma" content="no-cache" />
<meta http-equiv="expires" content="0" />Different browsers implement and interpret these instructions differently. IE5 through IE8 do not work well with pragma no-store. no-cache therefore is the compromise for backwards compatability. [2]
2.10 Issue : TLS V1.0 available
Presents as
HTTPS TLS v1.0 is available IF negotiated.
Mitigation
For backwards compatibility of TLS and earlier browsers which are end of life, TLS 1.0 is still available but only through negotiation as stronger encryptions are presented by default. What_browsers_does_bxp_work_on?
2.11 Issue : Reflective Cross-Site Scripting (XSS)
Presents as
Through specially crafted query string parameters JavaScript can be injected into operations.
Mitigation
As mentioned previously bxp facilitates client systems ability to support this capability on purpose for custom client applications and interaction with 3rd party solutions such as diallers and other "inside firewall" systems which require interactions.
2.12 Issue : Sensitive Information Exposure - Server Response Headers
Presents as
Cookies and response headers provide technology specific information facilitating targetted attacks.
Mitigation
bxp as part of it's compliance and regulation management provides a number of details about it's service publicly which mitigate the sensitivity of cookie and header information. The_bxp_Infrastructure
The hamster engine of bxp relies on information from a validly logged in user to provide technical support as to the nature of the issue that's occurred to allow a client to correct their own errors. The modules of MetaData and KeyStats are the two primary examples of where this matters most. Meet_the_Hamsters
2.13 Issue : Unprotected file upload
Presents as
Malicious files can be uploaded into bxp.
Mitigation
bxp facilitates clients with sufficient permissions the ability to add .js files to the engine for their own operations. eCourse pages facilitate a wider variety of supported materials. On all uploaders there are mime type approved lists. AntiVirus solutions monitor in real time all uploads with eicar being used extensively to monitor file upload points.
All upload points are limited and auditable.
2.14 Issue : httpOnly not applied
Presents as
The httpOnly flag not applied
Mitigation
Due to the implementation of the httpOnly flag using IIS Response.AddHeader "Set-Cookie" implementation to set a cookie flag at the end of the page, results in some testing software not properly detecting that the flag has been set. As bxp has to provide an HTTP implementation for backwards compatibility the httpOnly flag cannot be universally set by IIS and is implemented therefore in this fashion.
2.15 Issue : Cipher Suite Updates
Presents as
Bxp using legacy ciphers that do not support Forward secrecy
Mitigation
Forward Secrecy : We are reviewing our weblog reports to see what browsers / Operating systems are being used within bxp. This will allow us to create a more updated cipher suite listing. In some instances we may need to keep certain ciphers alive to support clients using legacy systems. With regard to forward secrecy we are currently testing the following cipher suite:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,