A security note for web developers
0 likes435 views
The document provides essential security design practices for web developers, emphasizing the importance of confidentiality, integrity, and availability in web applications. It reviews the OWASP Top 10 vulnerabilities and suggests strategies for secure coding, session management, password handling, and proper web deployment. Developers are encouraged to implement measures like data validation, session security, and using HTTPS to protect against common threats.
A security note for web developers
- 1. Basic Web Security Design for Developers By John (Troon) Ombagi A security note to web developers on how they can instill safe security design practices on their web development projects. @iLabAfrica
- 2. 1 Basic Web Security Design for Developers Fundamentals of Information Security The basic fundamental concept of information security is to establish Confidentiality, Integrity, and Availability. Only authorized persons should be able to access certain information. This information should be trusted (not manipulated or corrupted in any ways) and has to be there whenever needed. Security is a tradeoff. Tightening a website security means sacrificing some functionalities and/or usability. Take for instance the Google search engine, imagine answering a captcha challenge each time you want to make a search request. Irritating, right? Designing your website security and utilization of security within your web application means you have to identify and understand what you are trying to protect (threat modeling). After figuring out your potential threats, you work towards balancing functionality and usability. For instance a social media web application can register a client’s session for a longer time compared to an internet banking website, they both have different impacts in case of a session abuse.
- 3. 2 OWASP TOP 10 OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. The primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most important web application security weaknesses. The Top 10 list provides basic techniques to protect against these high risk problem areas and also provides guidance on how to mitigate these risks (https://storage.googleapis.com/google-code-archive- downloads/v2/code.google.com/owasptop10/OWASP%20Top%2010%20-%202013.pdf). The OWASP community is actively working on OWASP TOP 10 for 2017. Currently (at the time of writing), release for 2013 remains the official current final release and the most critical web application security risks are: A1 Injection A2 Broken Authentication and Session Management A3 Cross-Site Scripting (XSS) A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross-Site Request Forgery (CSRF) A9 Using Components with Known Vulnerabilities A10 Unvalidated Redirects and Forwards
- 4. 3 A Security Note for Web Developers. As a penetration tester, there are common vulnerabilities and misconfigurations that appear across different web application testing engagements. This section dives into some of these common vulnerabilities (pointing back to the OWASP Top 10, 2013) from a security testing point of view and explains how developers can avoid (or minimize) making these common mistakes. Remember, some of these security issues might have no impact in your web application, it’s important to understand your threats and what matters most in the critical parts of your web application. 1). Input Validation (A1, A3) Any point in your web application where data from untrusted source is take in, should be looked into with special attention. Untrusted data source is any source that provides data that you didn’t generate or data coming outside the application like user inputs. Your intended web application users can be the abusers. Always validate any data input. This helps cut down injection and XSS attacks. a) Client-Side then Backend Many web developers use JavaScript to validate user input and assume this is enough! Client side data validation can be bypassed by placing a proxy between a browser and a web application. Make sure you do another data validation at the back-end before processing requests from the client side. b) Regex and Blacklisting are hard. Another big mistake web developers do is trying to create their own filters for data validation by using regular expressions (regex). Most of these filters can be bypassed by abusing a rule not captured in the developer’s applied filter. There is so much bad data to filter, defining these unwanted data (black listing) is harder compared to defining what a clean data is (whitelisting). Make use whitelisting, set input size limits, check for data-types and stripe all web tags from data inputs.
- 5. 4 2). Securing sessions (A2, A4, A8) HTTP is stateless. For persistence, session association and/or authorization, session IDs, cookies or anything unique that can be stored in the client side and used in HTTP request employs a sense of session identity. If these elements of identity in a web application are not well secured, they may break authorization or affect the validity of user sessions. a). Don't Reuse Session IDs If a web application generates a unique session ID each time a user visits, that’s fine. The problem though, is when a user signs in a web application and the same session ID generated when unauthenticated is reused when authenticated. An attacker can perform what is known as a session fixation. b) Remove Session IDs from URLs Session IDs should not form part of an URL in any of the web requests. If there is a redirection to an external web resource, the redirection might leak out the session ID. One can use secure HTTP headers for session IDs. If possible, avoid URL redirections in your web application, if you must them, then specify URLs that are allowed and notify the user whenever redirecting out to external websites. c) Track Sessions A good web application should alert a user whenever an existing valid session is available in the web server and yet another new session has been created. For all established sessions, the web-server should be able to track them and make them expire after a period of time prompting the user to login again. Another important security design feature web developers can employ is enforcing users to re-authenticate when doing a critical action on a web application like deleting an account or making a card transaction. d) How random is random? Session IDs should be as random as possible. If an attacker is able to predict the next session ID a web application is going to generate, the users are at risk. These session IDs should be unique and hard to brute force. e) Don’t transmit Session IDs in Clear Text An attacker sniffing packets in a network can capture session IDs transmitted in plain text. Using SSL/TLS enables web application users use secure
- 6. 5 communication channels that don’t transmit data in clear plain text. Some web developers assume encoding these IDs solves the problem of transmission over a protocol that carry data in plain text. Encoding is not encrypting. A base64 encoded string can be decoded. 3) Data Transmission Security (A6) As mentioned earlier, HTTP is an insecure channel for transmitting data that is supposed to be kept private like credentials. Using HTTPS forms a secure communication exchange channel for transmitting data in a web application. Unfortunately, the green padlock on a client’s browser is not enough. How HTTPS is implemented matters a lot. A web application should not mix HTTP and HTTPS content. A web application developer should have in mind users initiating a connection (like getting a login page) over HTTP or users under a downgrade attack (HTTPS to HTTP). Below are some Security Header to help improve the secure data exchange channels in a web application by enforcing secure browser headers. These headers add checks and controls on the client-side that the server can’t directly control. i) HTTP Strict Transport Security (HSTS). With HSTS, a user makes only one insecure connection and upon receiving a response with HSTS header, all other requests will be made secure by using internal redirection 307 before reaching out to the webserver. ii) HTTP Public Key Pinning (HPKP) is another great way of protecting the web users against compromised SSL certificates. Public key pinning allows trusted SSL certificates to be whitelisted and instructs the browser on how to behave in the future whenever interacting with the web application in a secure channel. iii) Lastly, we have Content Security Policy (CSP) which provides a way of white-listing what resources your web application is allowed to load and which scripts to run. This prevents attackers from embedding external resource in the web application or modifying the document object model (DOM).
- 7. 6 4) Password Management (A4, A7) Passwords allow users to be authenticated in a web application, in case of an attack, they should be in a format that doesn’t expose actual passwords of the registered users. Passwords should not be stored in the back-end, in plaintext. Use password salting and peppering algorithms to disguise the initial password before storage. Don’t roll out your own crypto (unless you are good at it and whatever you have created has been tested and approved by other crypto experts). Use provided crypto libraries within your development frameworks. For instance, here are some publicly tested and approved cryptographic libraries you can use in your web application, bcrypt, PBKDF2 (key derivation function) or scrypt. I) Password validation Some web developers force users to use a certain pattern in their password creation. This is not entirely bad but still it discourages the users from creating complex passwords they can remember. Instead just use an indicator for strong and weak passwords (you can use something like this http://davidstutz.github.io/bootstrap-strength-meter without enforcing a particular format. Also, a strict password pattern means an attacker can use a rule-based password cracking technique which increases the chances of positive results.
- 8. 7 ii) Account Enumeration Login and password rest forms should not be too detailed. If a user doesn’t exist in a web application or maybe the password is wrong, give a generic message that an attack cannot tell which one of the two is valid and which one is not. On password reset make the user submit something he/she knows or he/she has before disclosing any personal identifiable information (PII). For example https://accounts.ecitizen.go.ke/forgot-password has a very bad password rest feature (you can enter anyone’s/random email or increment your ID number with 1 to get another person’s PII). If a user provides an email or ID, let the user provide the phone number used during registration and send a validation token via SMS for him/her to continue with the reset process. iii) Brute-force Attacks A good web application should counter any automated tool that send a lot of web requests in a very short time. Introduce a captcha on every critical web form in your website or simply show the captcha once you notice presences of an automation tool sending requests e.g. web headers from such known tools (like web scanners) and request time (if a lot of request are done in milliseconds and originate from a single user, it is likely an automation). Another way of countering brute-force attacks is using unique IDs for each HTTP response that must be included in the HTTP requests. This ID should not be reused or easy to predict the next one. One can also throttle requests from a particular client that is suspected of sending automated/malicious requests.
- 9. 8 5) Web Deployment (A6, A5, A9) Choosing where to host your web application is very important. Some web apps might require a dedicated hosting rather than a shared hosting. Another things to consider for your hosting is scalability, availability, extra layer of security (like against DOS attacks) and it should be a reputable hosting company. Other things that can go wrong in web deployment: Running other multiple services that you don’t need on a web server. Using outdated software/applications on a web-server Not updating a web server’s OS and running old/unpatched applications Binding critical services (like MySQL) on a public IP o Use 127.0.0.1 unless it’s intended to be accessed remotely by other services on a public IP Using a super user account for every service running on a server o Employ principle of lest privilege. Not setting folder permissions on the web server Using default credentials (a common sucker!) Not having a backup policy o In case things get out of control, you should be able to bounce back – business continuity is a real thing Hosting in countries under oppressive regimes or civil war etc. o Do you want free web hosting in Turkmenistan? Defense in depth is always important when trying to secure anything. So installing a Web Application Firewall can reduce some of the aforementioned common attacks. Log everything on your web server and make sure the time is correctly set (use Network Time Protocol), this will save headaches when responding to a security incident and recreating events timeline. John Ombagi, IT Security Assistant, @iLabAfrica jnyabuti@strathmore.edu