This is on 11th rank in top 25 CWE list. In this, the software performs an operation at a privilege level that is higher than the minimum level required which creates new weaknesses or amplifies the consequences of other weaknesses. This counted under OWASP A5 - Security Misconfiguration.
Under Architecture and Design; Operation phases, run code under lowest privileges. Create isolated accounts.
Under Architecture and Design phase, identify the functionality that requires additional privileges. Raise privileges as late as possible, and drop them as soon as possible, protecting all possible communication channels that could interact with the privileged code.
Under phase Implementation, extensive input validation for any privileged code
Under Implementation phase, make sure calls to remove permissions will not break.
Under Implementation phase, explicitly allow those actions while denying all else.
Under Operation; System Configuration phases, follow hardened configuration guide to limit the attack surface and potential risk of deployed software.
CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
This is 22 in top 25 list. If a website knowingly or unknowing allows user/attacker to input external website address and allow redirect then it is Open Redirect vulnerability. This comes under OWASP A10 - Unvalidated Redirects and Forwards
Assume all inputs are malicious while implementation phase.
During Architecture and Design phase user must be planned to be informed while leaving current application in a very clear and visible manner.
During Architecture and Design phase, if possible inputs are limited, free to type inputs should be avoided.
During Architecture and Design phase, ensure that redirects are confirmed to be originated from inside the app by using legitimate encryption/ random numbers.
During Architecture and Design; Implementation, highlight all the possible input methods including indirect methods like api calls , external systems cookies and so on.
During Operation phase, use application firewall.
How would you check for SQL Injections?
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Detecting exploiting and avoiding SQL Injection is consider being simple and it’s No 1 in to CWE list, categorized under OWASP A1 - Injection. Without sanitizing inputs from external system/users, inputs may be interpreted as SQL commands and executed to reveal internal hidden information or change sensitive data.
SQL injection could be avoided using Parameterized Queries, using Stored Procedures, sanitizing user inputs, whitelist input validation and minimizing privileges assigned to every database account.
Various automated dynamic/static analysis tools are available to detect SQL injection but it should be taken care of at Architecture and Design, Implementation and operation phases with due care.
During Architecture and Design phase various frameworks maybe used which prevent SQL injection, separation b/w data and code could be enforced, least permission rule may be enforced, client side and server side validations could be enforced, inputs may be limited by from predefined options if possible and so on.
During Implementation phase, all inputs must be assumed to be dirty, escape or filter all characters that do not pass predefined whitelist, strict error handling and error messages, legitimate output messages to operation which won't reveal internal specifications of the system and so on.
During Operation phase least permission rule may be enforced and appropriate firewall rules may be enforced.