Vikas Chourasiya
BAN USERWhen you say CPU utilization goes down to zero, are you talk about CPU utilization for this process alone. What is the memory utilization for this process, is it constant, If yes, Then, It may be due to high priority process switching the context and
- May be in a deadlock.
- Waiting for I/O.
This is a very open ended question, with no specific answer, Though, The answer can be given as below:-
The security should be looked in a complete sense, right from installation, access rules, Audit Trail, Back Restore, Privileges, Credential prevention etc.
- In DB's like IBM DB2, it needs a system user to be created, thus, security of the system user is also important. Choose a strong password for the instance user, never use the default username/password for configuration.
- Follow the principle of least privilege, The web application connecting to the database should use a low privilege user account, which is allowed only to execute bare minimum scripts to fulfill the deeds of the application and nothing more.
- The application should not store username/password in plain text in any application configuration files. It should be encoded and then used.
- Its always better to create a datasource and use JNDI lookup.
- Ensure the number of sockets available in the system complements the number of connections that you anticipate to the database from any form of DB connection.
- Perform bound checking for any user inputs.
- Use parameterized SQL queries, in case you are using plain JDBC, Or better go for an ORM.
- Do not create tables in the default schema.
- Review code for functions/triggers/procedures which are present in the database.
- Ensure the sql scripts are encrypted [Eg. use TDE, SQLShield etc]
Take a step back and perform threat modelling for the web application to find out the threats/attack surface/end points, Then, start by mitigating risks with each input source, eg:-
- Vikas Chourasiya December 01, 2013User Input:
- Bound Checking.
- Output encoding to avoid XSS.
- Never use blacklist to prevent XSS.
- Never trust session identifiers from user, treat them as any other input from the user and perform validation on the session identifiers.
- Update the session identifier on user state change to prevent session fixation.
- Perform query string filteration to avoid XSS.
- Use nonce in all the web pages generated by the web server to avoid CSRF.
- Always check HTTP REFERRER header to make decisions about valid and forged requests.
- Set session cookies in a secure manner [isSecure, httpOnly, isSession]
- Always use no-cache, no-store META information for pages which shouldn't be cached by browser.
- Use ORM or parameterized queries to avoid blind sql injection.
- Use custom exception handling for sql error's to prevent information leakage.
The list is just a start and there are many more considerations to security.