Since the web is the most fragile space when it comes to cyber attacks, you app is a target; it’s essential to foresee the force majeure and proper ways to secure your project.
Step 1. Privacy-by-Design
Being compliant to privacy numerous legislation is a must if you want to breathe freely and guarantee your users safe journey when using your web app.
Having drawn its inspiration from California’s first of a kind SB1386 bill of 2003, EU’s GDPR or General Data Protection Regulation is a law that enhances data-breach notifications and total encryption of data making digitalization a subject to personal data protection. A refined version of GPPR is to come to an effect in May 25th, 2018. From now on, right to access and shift to data transparency, empowerment of data subjects changes are drastic. Data Erasure or Right to be Forgotten would allow the data subject to have the data controller delete his personal data, end further circulation of it as well as to have any third-party stop using that data. Study what your web application security needs to comply with existing rules and regulations.
Step 2. Determine Highly Vulnerable Areas of the App
What are the gaps that you will need to fill in to safeguard the security of your web app? To focus on what really matters, think of users that can be affected by poor web application security. Probably those of your team members who administer and maintain your app are unlikely to do much harm since they’re subject to internal policies everyone on board is aware of.
However, another category of users, “outsiders” using your app - your target audience might intentionally or not do bad to your web. How? They might want to add, change, or completely delete some content affecting web application security and ruin hours of hard work jeopardizing the whole app performance. Use verification on input sanitization and output encodings to prevent this misfortune happening.
Step 3. Design Bullet-Proof Business Logic and Overall Software Architecture
This step covers design of manual tests that target several areas related to sensitive information such as:
- Revealing of sensitive data.
Here, you have a few ways to construct the business logic process. First, you can go for data flow specific approach or choose a second option which would be tailored to the business logic of your web application. Subject matter experts suggest that this part of work might be neglected by automated tests; thus, this is where testing the waters manually comes in handy.
For instance, the areas for manual testing might cover approval workflow and special account access where an engineer can make sure that:
- The workflow is integral;
- Users can’t avoid certain workflow steps;
- Users can’t do certain things without obtaining a prior permission.
Step 4. Create Authentication Everywhere and Log Everything
Follow established industry best practices for web authentication to avoid user credentials leaks.This list is not exhaustive but it will give you some ideas on what areas of your web app architecture to look into in order to improve web application security.
The aim of logging in is to allow the application identify who the user is and to grant specific privileges accordingly or restrict him from accessing particular areas of the app. Furthermore, consider some of the following tips to increase the security levels:
- Employ https for everything related to authentication;
- Don’t write out any sensitive information to STDOUT or a log file;
- Hash your passwords with a strong, certified, and slow cryptographic one-way hashing scheme
- Salt your hashes, using a separate salt for each string you hash.
- Separate sensitive info from usual data
Additionally, you can use OTP or One-time passwords if you have a two-step authentication where a user enters his credentials and after both the server and the client generate a respective OTP.
Step 5. Perform Total Test Coverage
Once you have both the manual and automated test cases laid out, perform those step-by-step and document the findings to refine the vulnerabilities discovered. These are some of the suggestion you can go with when it comes to web app testing might include:
- Test by inserting internal URL directly into the browser address line without login. Internal pages should not open.
- When logged in with credentials, try directly changing the URL site ID parameter to different site ID which is not related to the logged in user. Access should be denied for this user to view others stats.
- Try some invalid inputs in input fields like login username, password, input text boxes etc. Check the system’s reaction to all invalid inputs.
- Web directories or files should not be accessible directly unless they are given download option.
- Test if SSL is used for security measures. If it is used, the proper message should get displayed when user switch from non-secure HTTP:// pages to secure HTTPS:// pages and reverse.
- Test the CAPTCHA for automating script logins.
- All transactions, error messages, security breach attempts should get logged in log files somewhere on the web server.
Here, you can find some additional tips to help you deal with your web app security. Consider it a lessons-learned bundle from a seasoned pro, Michael O’Brien where through the lenses of his personal experience, he tailors a set of tips to consider:
- For user-specific personal data, use encryption
- To protect data on disk, enable low cost encryption at rest
- Instead of database root account, use minimal privilege to enable your database access user account.
- Using a key store designed for the purpose, store and distribute secrets.
- Make sure that you inspect oll of the parts of your software for are scanned for possible weaknesses.
- Create the software from secured, isolated development systems.
Denial of Service Protection
- Ensure that DOS attacks on your APIs won’t affect your site. At least, have token generation routines. To top it off, employ CAPTCHA on front-end APIs to protect back-end services against DOS.
- Use DDOS mitigation through a globally trusted caching proxy service to like Incapsula. This can be used as a DNS lookup in case you encounter a DDOS attack
- Set the right limits for amount and structure of data and requests submitted by users.
- Along with login forms and responses, employ TLS for your entire site. Moreover, use the strict-transport-security header to force HTTPS on all requests.
- Entre cookies have to be http only and secure and be scoped by path and domain.
- Use X-Frame-Option, X-XSS-Protection headers in client responses. Use https://observatory.mozilla.org to score your site.
- Use HSTS responses to force TLS only access. Redirect all HTTP request to HTTPS on the server as backup.
- Use CSP without allowing unsafe-* backdoors. It is a pain to configure, but worthwhile. Use CSP Sub-resource Integrity for CDN content.
- Use CSRF tokens in all forms and use the new SameSite Cookieresponse header which fixes CSRF once and for all newer browsers.
- Ensure that no resources are enumerable in your public APIs and users are fully authenticated and authorized appropriately when using your APIs.
- Use canary checks in APIs to detect illegal or abnormal requests that indicate attacks.
Validation and Encoding
- Perform client-side input validation for quick user feedback, but trust it blindly. Before displaying, always validate and encode user input.
- Verify each of user input using white lists on the server. Never directly inject user content into responses. Never use suspicious user input in SQL statements or other server-side logic.
- Ensure all services have minimum ports open. While security through obscurity is no protection, using non-standard ports will make it a little bit harder for attackers.
- Host backend database and services on private VPCs that are not visible on any public network. Be very careful when configuring AWS security groups and peering VPCs which can inadvertently make services visible to the public.
- Isolate logical services in separate VPCs and peer VPCs to provide inter-service communication.
- Ensure all services only accept data from a minimal set of IP addresses.
- Restrict outgoing IP and port traffic to minimize APTs and “botification”.
- At any time, use AWS IAM roles and not root credentials.
- Use minimal access privilege for all ops and developer staff.
- Perform passwords and access keys rotation in accordance to a schedule.
- Ensure you can do upgrades without downtime. Ensure you can quickly update software in a fully automated manner.
- Build all infrastructures using a tool such as Terraform, and not via the cloud console. Infrastructure should be defined as “code” and be able to be recreated at the push of a button. Have zero tolerance for any resource created in the cloud by hand – Terraform can then audit your configuration.
- Don’t SSH into services except for one-off diagnosis. Using SSH on regular basis, typically means you have not automated an important task.
- Use centralized logging for all services. You should never need SSH to access or retrieve logs.
- Don’t keep port 22 open on any AWS service groups on a permanent basis. If you must use SSH, only use public key authentication and not passwords.
- Create immutable hosts instead of long-lived servers that you patch and upgrade. (See Immutable Infrastructure Can Be More Secure).
- Use an Intrusion Detection System to minimize APTs.
- Turn off services and servers that are not in use. Remember, the most reliable server is one that is powered down. It’s necessary to schedule development servers power off at times when they’re not required.
As you can see, there are numerous points to account for when thinking through your web application security. No man is an island, so it’s essential to assemble a reliable team of professionals that knows how to deal with each section of the checklist. Afterwards, synthesizing the expertise and seeing if all the components together are as secure as they’re when standalone, is crucial.