OWASP Top 10 list

OWASP Top 10 list is created by a group of top security exports globally.

External Data threats

Means user input. Solution is to validate input and sanitize input.

Injection flaws. Passing user input data to an interpret without validating it. Scanners can be used to locate such flaws. Impact would be to expose data to unauthorized users. Tip: only give the app the privilege it needs so that even if there is injection, the impact is minimized. Validate if a input parameter is treated as data only, not as executable.

XML External Entities (XXE). Hackers insert malicious content in xml for exploitation such as extracting data without being unauthorized. Using an old parser and enabling DTD (Document type definition) makes xml vulnerable. Tips: disable xml external entity and DTD processing in xml parsers.

Cross-Site Scripting (XSS). This attacks target end user’s browser. It could end up stealing sessions.

• stored XSS: malicious code is stored in database
• Reflected XSS: code in browser use unsanitized input directly. Those input could cause harm.
• DOM XSS: be aware of ways uncontrollable data could be included on the page

Tips: escape form input.

Insecure Deserialization. This occurs the app accept serialized data from untrusted source and try to deserialize it. Tip: log all deserialization exceptions or errors.

Infrastructure threats

Sensitive Data Exposure. Make sure sensitive data transmitted externally or internally are not transmitted in plaintext. Sensitive data should not stored in plaintext.

Security Misconfiguration. Unpatched software could be a weakness. Hardening: remove unnecessary features, configure each environment identically.

Using components with known vulnerabilities. Consider patching scheduling. Too long could expose the app to risks.

Insufficient logging and monitoring. Logging is to detect probing, such as malicious login attempts. If such activities are not detected, it could leave to breach. Tip: log logins, failed login, and high-value transactions. We also want the system able to detect real-time attacks. Logs needs to be monitored with threshold set for suspicious activity. Organization needs to have escalation process otherwise the app may stay vulnerable.

Protect again logging flaws. Create formatted logs and include contexts for identifying suspicious activity. For high-value transaction, such as payment record, put it in audit trail to prevent tampering. Set up alert in order to respond to suspicious activity in a timely fashion.

ID threats

id threats means broken authentication or broken access control.

Broken authentication flaw. An app has broken authentication flaw when it allows too many failed login attempts, weak passwords, and rely only on password. It is dangerous to put session id in the url. Tips: do not provide default credentials, check for common and previously used passwords; do not reveal information to attackers for failed login, password recovery, use same error message all of these scenarios. Log all login failures and alert admin when threshold is breached. Invalid session id after log-out or idle.

Broken access control flaw. This might give user unauthorized access to the app. Tip: set up RBAC; rate limit API to prevent automated attack tool; log all access control failures; alert admin when the failures pass a threshold; invalidate authentication token on server side after logout; establish record ownership via access control, rather than allow user to CRUD any records, I think one way to do it is for updating/getting/deleting a record, check if the requester is the owner of the record; use second factor for account recovery rather than knowledge-based questions.

Other threats

Buffer Overflow

Insecure Communication. such as using non-SSL channel, sending sensitive data with unencrypted communication channel.

Cross-site-request-forgery. Trick user to submit a request to a legitimate site benefiting a attacker. For example, a attacker can trick a user to send a request to a bank website that the user logins into, and transfer money to the attacker. The attacker can construct a url and use social engineerings to trick the user to click on it. One way to do it is via sending an email to the victim, the email could contain a link to the url (that looks like something else), or include a 0x0 image of which contains the url in the src.

Improper Error Handling Error message that reveal internal implementation of the site is not secure. Error message should contain meaningful info to users, diagnostic info to developers, and no useful information to attackers. We should log error messages with the cause, whether an normal error or a hacking attempt, can be viewed. Error handling should be consistent across the site, each piece should be a well-designed scheme. An error handling policy should be documented, such as the type of errors and for each, what is reported to user and what to be logged. I think in a frontend application, there are validation errors, logic errors, api errors, error responses from api. Some kind of errors should be logged for detecting hacking attempt.

Insecure Authorization. This is low-privileged user are allowed to perform high-privilege actions. One reason this is happening is the backend does not check the authorization of a request because it assumes such request wouldn’t be made by a low-privilege user. But an attacker can crack the binary of the mobile device and find the hidden endpoint. I think backend should verify that a user can only authorized to operate on objects belong to them.

Insufficient Cryptography. Always assume the OS-provided binary encryption can be by-passed. Using free tools, attackers can get the unencrypted version of the binary and perform analysis and conduct attacks. Saving keys in binary is dangerous because attackers could get it. Always use algorithm that accepted as strong by the security community. Using your own algorithm is the least secure of all. MD5 and SHA1 are deprecated.

Improper Session Handling. This allows another user impersonate an user. We should invalidate a token after logging out. For example, a attacker steals a user’s jwt token through social engineering and get access to a victim’s computer, the attack steals the token. Now the user logs out, the attacker still can access the user’s data even after the user found out it has been stolen. The solution is to blacklist the jwt token in the backend. The backend also should timeout a token after a certain amount of time of inactivity to prevent malicious users access to users’ session after the user stops using the app.

Software and Data Integrity Failures. Such as firmware updates without verifying its signature.