Are you sure that your web application is protected against cyber attacks? Is it possible for an attacker to get unauthorized access of your web application? Here I would like to focus on some of the major issues which need to be fixed while programming. Nowadays lots of automatic security audit tools are available in the market so it is better to use those tools however manual testing is a must for better and improved security.
Here, I am giving the parameters for better security measures:
Encrypted Login Pages:
After user authentication is accomplished, lots of web applications use only Secure Socket Layer as a security measure, which is not a safe practice. After login, “Session Encryption” may be useful but failing to encrypt logins is like leaving the key in the lock when you’re done locking the door. SSL provides no protection beyond the session, and an SSL-enabled Web server cannot protect the text data file stored on the server. SSL provides no protection against Web-based attacks such as exploiting a flaw with a Common Gateway Interface (CGI) script. If your login form POSTs to an encrypted resource, in many cases this security can be bypassed by a malicious security cracker who deploys his own login form to access the same resource and he may get access to sensitive information.
Server Side Data Validation:
At times hackers bypass JavaScript to submit the malicious data on your webserver therefore you need a good and proper validation on your webserver. Many web application’s forms include JavaScript data validation. A malicious security cracker can deploy a form of his own that accesses the resource at the other end of the Web page’s form action that doesn’t include any validation at all. Rejected Data must not be persisted to the data store unless it is scanned properly. This is a common mistake to log incorrect data and that may be what the attacker wishes your application to do.
In many cases of JavaScript form, validation can be bypassed by just deactivating JavaScript in the web browser or by using a Web browser that doesn’t support JavaScript at all. Some programmers validate the password at client-side. If you are one of those then better leave this practice as these login pages can expose the passwords to the end user via the ability to view page source or, allows the end user to alter the web form so that it always reports successful validation.
Secure/Encrypted Connections:
Programmers commit a common mistake by using unencrypted connections such as unencrypted FTP or HTTP for Web site or Web server management. Unencrypted or weak connections can make your web application vulnerable via man-in-the-middle attacks and login/password sniffing. Always use encrypted protocols such as Secure Shell ( SSH) to access secure resources, using secure tools such as OpenSSH. It is a FREE version of the SSH connectivity tools that technical users of the Internet rely on. Once someone has gained your login and password information, that person can do anything you could have done.
Use strong, cross-platform compatible encryption: For secure data transfer use SSL ( Secure Socket Layer) certificate. Transport Layer Security (TLS) — the successor to Secure Socket Layer encryption can also be used. Make sure any encryption solution you choose doesn’t unnecessarily limit your end user base as this can lead to lesser web traffic.
Connect to a Secure Network:
Avoid connecting with unknown networks or with known poor security network such as open wireless access points in coffee houses etc. This is especially important whenever you log in to the server or Web site for administrative purposes or access secure resources. If it is necessary to access the Web site or Web server using an unsecured network, use a secure proxy so that your connection to the secure resource comes from a proxy on a secured network. You can use a virtual private network (VPN) connection that encrypts all the data between a device and a VPN server on the other end.
Never Share Login Details:
Shared login credentials can cause a number of problems for security. This applies not only to you, Web server administrator, but to people with login credentials for the website as well — even clients should never share login details. The more those are shared, the more difficult it is to establish an audit trail to help track down the source of a security breach or threat.
Prefer Key-based Authentication:
Use cryptographic key-based authentication for password authentication. The distinguishing technique used in public key cryptography is the use of asymmetric key algorithms, where the key used to encrypt a message is not the same as the key used to decrypt it. Each user has a pair of cryptographic keys - a public encryption key and a private decryption key. The publicly available encrypting-key is widely distributed, while the private decrypting-key is known only to the recipient. Messages are encrypted with the recipient's public key and can only be decrypted with the corresponding private key.
Maintain a Secure Workstation:
Work station audit is required in order to be sure that no key-logger or any other malicious software is lying on the computer. Because it can lead to un-authorised access to sensitive information regardless of all the security eg secured networks, encrypted communications, and other networking protections. If you connect to a secure resource from a client system and you are not sure about its security, then how can you be sure that someone isn’t “listening in” on everything that you are doing. So workstation auditing may be the only way to be sure, with any certainty, that your workstation has not been compromised.
For more articles visit www.cybersecuritydelhi.com
No comments:
Post a Comment