[DI-2.3] Security Design

[jtam360]

-List proposed security measures to be added -Rank proposals by priority and feasibility -Provide brief design plan of how the security measures are to be implemented -Server should have SSL -Login protection (sql injection, etc) -Final polishing of the database interface's security -Provide metrics for the expected security capabilities (the level of security we are promising)

child of #14 connects #14

[jtam360]

Security Measures: This list is constructed using OWASP's Top 10 -2017 Web Security Vulnerabilities, I added any additional security measures that are either important or can be easily implemented. OWASP: https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

1. "Security through obscurity" - Hiding our login authentication/session cookies
2. Injection - SQL, NoSQL and OS injections. Hostile data to execute unintended commands.
3. Broken Authentication - User authentication/session management functions.
4. Sensitive Data Exposure - Attackers stealing weakly protected data.
5. XML External Entities (XXE) - Includes DDoS attacks, remote code execution, etc.
6. Broken Access Control - Enforcing restrictions on what authenticated users are allowed to do.
7. Security Misconfiguration - Insecure default configurations, open cloud storage, etc.
8. Cross-Site Scripting (XSS) - Including untrusted data in web page without validation. Includes updating web page with user-supplied data.
9. Insecure Deserialization - node.serialize and serialize-to-js are inherently insecure. Reference: https://www.acunetix.com/blog/web-security-zone/deserialization-vulnerabilities-attacking-deserialization-in-js/
10. Using Components with Known Vulnerabilities - Including insecure components can compromise the entire system.
11. Insufficient Logging & Monitoring - In addition to ineffective incident response can allow attackers to attack deeper systems, tamper/extract/destroy data. "Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring."

Feasibility Report:

1. Probably the first and most important step when implementing our security is to encrypt and protect user/pass along with our session cookies. We don't want to simply attempt to hide the login authentication information on the backend because that is still vulnerable. Rather we will need to encrypt the user/pass at rest and in transit to authenticate users. A similar approach should be implemented with session cookies, along with additional cookie tags that prevent cookies to be altered/created with JavaScript. To get started on encrypting we can try to implement a simple cipher using node.js built in Crypto Module.
2. I think this is similar to cross-site scripting but more direct. I'm not an expert at injections but I think it'll be worth it to at the least include some sort of user input sanitation to prevent malicious code to be executed within the browser. I tried myself to run JavaScript within our login form but I couldn't get it to work.
3. We can improve our current user authentication by filtering user input to prevent unintended outputs.
4. I think this might be a bit challenging to tackle, if we want to protect our data. My first thought that comes to mind would be encrypting all the jsons, including the archives. Then when reading the json we would have to decrypt and display it.
5. We can't realistically stop DDoS attacks, I think that our application in its current state is relatively safe from being targeted from DDoS attacks.
6. We already implemented this in the form of session states with cookies, users aren't able to bypass access control by modifying the URL, although I'm not sure what would happen if they used a custom API attack tool. Elevation of privilege is an issue that we have to protect against, mainly through injections. We don't want users to be able to create session cookies for themselves so by securing the cookies created with HttpOnly tag, we can protect against this. This would be easy to implement unless there's another way to gain access to an account other than user/pass or cookies.
7. This would be difficult to implement because of our limited knowledge on server backends and components to deep scan our system for any misconfigurations. We can attempt to scan it towards the end to ensure there isn't a big gaping hole in security but ultimately I think this task would be too time consuming.
8. From my understanding of XSS attacks, a researcher or authenticated user would have to click some shady link that could compromise their browser to run malicious code. This sort of reflected XSS attack can be prevented with separating untrusted data from active browser content. This can be achieved through input filtering. Stored XSS attacks is often considered a high or critical risk, this is when the application stored unsanitized user input that is viewed at a later time by another user. Fortunately this isn't an issue for us as each user has their own session and sessions don't overlap. Feasibility-wise, we should be able to add some sort of input filtering.
9. This vulnerability relates to how we handle our json data and how the attacker can manipulate our logic and also our cookies. I haven't looked into more depth in how they attack these points so I'm not sure how to implement a defense yet.
10. I don't think this is feasible since we are by no means experts in any libraries/frameworks/components we use. We can attempt to verify that all the components we use are secure but it is more than likely that there will be some small vulnerability that can be exploited.
11. I don't think this is incredibly useful to us at this point in the application, although we can implement this as part of our stretch goals. To implement this, we would have to ensure that all login, login attempts/failed logins, and other audit-able events are logged with sufficient user context to identify suspicious or malicious accounts. We would also implement a login lockout feature where if a "suspicious" user attempts to log in over X times within X minutes then we prevent them from trying again. We would also have to ensure that logs are generated in a format that is easy to read and centralized. These logs should have an audit trail with integrity controls such as read-only access. We could also implement an alert system to alert developers of any suspicious activities that are detected so we can respond in a timely fashion. In addition, we can think to adopt an incident response and recovery plan, such as NIST: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

Overall, I'd recommend to focus on encrypting login credentials, session cookies, and protecting our data at rest and in transit. If we wanted to take security any further than we can set up a meeting with Dr. Aliasgari to discuss further security vulnerabilities.

[dionwu110]

Currently, our server has an SSL certificate:

Also, based on the SSL server test, we have received an A+ rating for our security at the moment.

Right now, we have basic certificates and configurations for our server. However, we can further improve our security by adding these. I previously attempted to implement some of these configurations for the security of our server such as adding TLS v1.3. However, I ran into some issues and got some errors through this process. But, I will try to fix this problem and also try to improve some of our ciphers.

[dionwu110]

Also, because we have basic certificates, we can maybe purchase more that can further increase our security such as buying a CAA certificate.