Security is playing vital role in your project . While devloping our application following areas we have to verify .
Area
|
What to look for
|
SQL injection
|
A SQL injection attack occurs when untrusted input can modify
the semantics of a SQL query in unexpected ways. As you review the code, make
sure that the SQL queries are parameterized and that any input used in a SQL
query is validated.
|
Cross-site scripting
|
Cross-site scripting occurs when an attacker manages to inject
script code into an application so that script code is echoed back and
executed in the security context of the application. This can allow an
attacker to steal user information, including forms data and cookies. This
vulnerability can be present whenever a Web application echoes unfiltered
user input back to Web content.
|
Data access
|
Look for improper storage of database connection strings and
proper use of authentication to the database.
|
Input/data validation
|
Look for client-side validation that is not backed by
server-side validation, poor validation techniques, and reliance on file
names or other insecure mechanisms to make security decisions.
|
Authentication
|
Look for weak passwords, clear-text credentials, overly long
sessions, and passwords or secrets being stored in session data
|
Authorization
|
Look for failure to limit database access, inadequate separation
of privileges, and mechanisms to work around authorization checks.
|
Sensitive data
|
Look for mismanagement of sensitive data by disclosing secrets
in error messages, code, memory, files, or the network.
|
Hard-coded secrets
|
Look for hard-coded secrets in code by looking for variable
names such as "key", "password", "pwd",
"secret", "hash", and "salt".
|
Poor error handling
|
Look for functions with missing error handlers or empty catch
blocks.
|
Too verbose error handling
|
Look for functions which do data integrity validation before
checking data access authorization. Such error handling may reveal too much
information about what is in the database to an unauthorized user.
|
Undocumented public interfaces
|
Most undocumented interfaces should not be in the application,
and they are almost never given the same level of design and test scrutiny as
the rest of the code. If an operation is exposed as a public interface, check
that it actually required.
|
Threading problems
|
Check for race conditions and deadlocks, especially in static
methods and constructors.
|
Unreleased resources
|
Look for allocation of resources for a request that are not
released when the request is serviced.
|
Assigning resources before authentication
|
Look for allocation of resources prior to authentication.
|