Development Common Security Mistake and Prevention, Detection technique

Development Common Security Mistake and Prevention, Detection technique
Development Common Security Mistake and Prevention, Detection technique

As more development shifts to the web and more data are stored in the cloud, security is a critically important topic. A single security misstep can compromise confidential business data or your customer’s personal information. While web application security is a broad topic, I’d like to focus on the security mistakes that web application developers should never make. These are the “basic” security principles that should never be ignored. I have listed some of the points only to give you an idea of the potential problems you might encounter.

Incomplete Input Validation

Authentication without proper Authorization

Security misconfiguration

Sensitive Data Exposure

Cross-Site Request Forgery (CSRF)

1. Incomplete Input Validation:-

Validation of user input should be on both client and server side. We do not trust user input. Implementing validation might be time-consuming, but it should be part of your standard coding practice and never set aside. One of the most common consequences of this mistake is SQL Injection.

Attack Types:
SQL Injection
Cross-site scripting

SQL Injection:- 

An SQL injection attack consists of insertion either a partial or complete SQL query via the data input or transmitted from the client (browser) to the web application.

A successful SQL injection attack can read sensitive data from the database, modify database data (insert/update/delete), execute administration operations on the database (such as shutdown the DBMS), etc.

Eg:

‘; DELETE Orders;–

‘ UNION SELECT name, type, id FROM emp;–

Prevention
prevent typing of characters such as semi-colon (;), dash (-) or percentage (%) that used in SQL Queries.

Cross-site Scripting:- 

Cross-site scripting (XSS) is a code injection attack that allows an attacker to execute malicious JavaScript in another user’s browser.

How the malicious JavaScript is injected-

<body onload=alert(‘test1’)>

<script>alert(‘hello’);</script)

Prevention
Stop accepting <script> and <html> start tags.

2. Authentication without proper Authorization:-

Authentication- Verifying that a person is a specific user since he/she has correctly provided their security credentials.
Authentication- Confirming that a particular user has access to a specific resource or is granted permission to perform a particular action.

Example:
Consider that your browser holds currently logged user information in an object similar to the following:
{
username:abc,
role:’dancer’,
token:’123456780′
}
When doing a password change, your application makes the POST:

POST /changepassword/:username/:newpassword

Then you find the user profile based on the :username parameter, and you change your user’s password. your /changepassword method, you verify that user is logged in and the token has not expired.

The browser can be tampered with, and an advanced user could easily update username:’elvis’ to username:’Administrator’ without using anything else but built-in browser tools.

Prevention:-
You need to make sure that you verify actual requester and content of request within your /changepassword method and implement proper Authorization of the request making sure that user can change only her data.

3. Security Misconfiguration:-

In my experience, web servers and applications that have been misconfigured are way more common than those that have been configured properly.
Examples:
a. Running the application with debugging enabled in production.b. Having directory listing enabled on the server, which leaks valuable information.

c. Running outdated software (think WordPress plugins, old PhpMyAdmin).

d. Having unnecessary services running on the machine.

e. Not changing default keys and passwords. (Happens way more frequently than you’d believe!)

f. Revealing error handling information to the attackers, such as stack traces.

4. Sensitive Data Exposure:-

Web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times.No exceptions. Credit card information and user passwords should never travel or be stored unencrypted.Session IDs and sensitive data should not be traveling in the URLs and sensitive cookies should have the secure flag on, this is very important.

Prevention
Use HTTPS with a proper certificate and Do not accept anything over NON-HTTPS connections. Have the secure flag on cookies.You need to lower your exposure.
If you have sensitive data that you actually do need, store it encrypted and make sure all passwords are hashed.

5. Cross-Site Request Forgery (CSRF):-

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf.

CSRF attacks target functionality that causes a state change on the server, such as changing the victim’s email address or password or purchasing something.

Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does. As such, CSRF attacks target state-changing requests.

Prevention:

Store a secret token in a hidden form field which is inaccessible from the 3rd party site. You always have to verify this hidden field. Some sites ask for your password as well when modifying sensitive settings.