1. SQL Injection Prevention Techniques
Commonly used tools for detecting & preventing SQL Injection attacks
SQL map: It is an open-source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking-over of database servers. It is commonly used in Kali-linux.
After finding a vulnerable page you can find database by typing:
sqlmap –u (url) –dbs
Key Points to check if you are vulnerable:
a. Unprotected user authentication credentials while storing using hashing or encryption.
Possibility of guessing or overwriting credentials because of weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
b. Exposed Session IDs in the URL (e.g., URL rewriting).
c. Session IDs are vulnerable to session fixation attacks.
d. Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, lack of proper invalidation during logout.
e. Passwords, session IDs, and other credentials are sent over unencrypted connections.
Session IDs aren’t rotated after successful login.
2. Protect your application against broken authentication and session management
Password strength:
a. Define minimum size and complexity. Complexity depends on the usage of combinations of alphabetic, numeric, and/or non-alphanumeric characters.
b. Change password periodically.
c. Prevent reusing previous passwords.
Password use:
a. Restrict to a small, finite number of login attempts per unit of time and log repeated failed login attempts.
b. System should not indicate whether it was the username or password that was wrong if a login attempt fails.
Password change controls:
a. Ask users to provide both their old and new password while changing their password.
b. If your system emails forgotten passwords to users, ask users to re-authenticate whenever they’re changing their email address. Otherwise, an attacker who has won temporary access to their session (e.g. by walking up to their computer while the actual user is logged in) can simply change their email address and request an email for ‘forgotten password”.
Password storage:
a. Store passwords in either hashed or encrypted form.
b. Use encryption whenever plain text password is required.
Session ID protection:
a. Protect the entire user session via SSL.
b. Never include Session ID in the URL as they can be cached by the browser.
c. Session IDs should be long, complicated, random numbers that are impossible to guess.
d. Change Session IDs frequently during a session to reduce how long a session ID is valid. One should also change Session IDs when switching to SSL, authenticating or other major transitions.
Browser caching:
a. Never submit authentication and session data as part of a GET. Always use POST method.
b. Always mark authentication pages with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser and backup to the login page and resubmit the previously typed in credentials.
3. Prevention from sensitive data exposure
a. Make sure you encrypt all sensitive data.
b. Don’t store sensitive data unnecessarily. Discard it as soon as possible. No one can steal the data that you don’t have, right?
c. Ensure using strong standard algorithms and strong keys.
d. Make sure proper key management is in place.
e. Ensure storing passwords with powerful password protection algorithms such as bcrypt, PBKDF2, or scrypt.
f. Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data.
4. XSS Prevention Techniques
To keep yourself safe from XSS, you must sanitize your input. Your application code should never output data received as input directly to the browser without checking it for malicious code.
The following rules are intended to prevent all XSS in your application. While these rules do not allow absolute freedom in putting untrusted data into an HTML document, they should cover most common use cases.
Rule:1
Never Insert Untrusted Data Except in Allowed Locations
The first ` – don’t put untrusted data into your HTML document unless it is within one of the slots. For example
In Java Script
Rule:2
When you want to put untrusted data directly into the HTML body somewhere. This includes inside normal tags like div, p, b, td, etc
Rule:3
Attribute Encode Before Inserting Untrusted Data into HTML Common Attributes
a. Always quote dynamic attributes with ” or ‘. Quoted attributes can only be broken out of with the corresponding quote, while unquoted attributes can be broken out of with many characters, including [space] % * + , – / ; < = > ^ and |.
b. Encode the corresponding quote: ” and ‘ should be encoded to " and ' respectively.
c. Some attributes can be used for attack event with encoding and should not be dynamic, or with extra care
Such as –
i. href can be used to inject JavaScript with javascript pseudo protocol (e.g. href=”javascript:attack())
ii. all event handlers (onclick, onerror, onmouseover, …) can be used to inject JavaScript
iii. osrc can also be used to inject external scripts depending on the context (e.g. in a script tag)
5. Prevention of Insecure direct object references
There are two strategies for avoiding Insecure Direct Object References, each is explained below:
1.Logically Validate References
2.Use Indirect References
Logical Validation
Every web-application should validate all untrusted inputs received with each HTTP Request. At a minimum, the application should perform “whitelist validation” on each input. This means verifying that the incoming value meets the applications expectations for that input, such as:
a. Minimum or maximum length
b. Minimum or maximum bounds (for numeric values)
c. Acceptable characters
d. Data Type (e.g. string, date, integer, rational, etc)
e. Set membership
f. Pattern (phone number, social security, Employer Id etc.)
“Whitelist validation” implies that the application imposes a specific set of checks on each input that must be satisfied, otherwise it is rejected. Note that Whitelist validation is all about what the input “looks like” and is unconcerned about what it “means”. Thus, we refer to whitelist validation as Syntactic Validation. As stated above, every untrusted input to the application must be subject to syntactic validation.
It is also possible to augment Syntactic Validation with Logical Validation, by adding checks to see if the given value makes sense. We cannot be specific here, because what “makes sense” depends on the application design and meaning of the input. Some examples will help to clarify:
a. The incoming “id” parameter represents a customer identifier, and it must be checked to ensure that the current user is authorized to access it.
b. The incoming “account” parameter identifies the user’s account, and it must be verified that it IS that users account.
Logical validation can eliminate Insecure Direct Object Reference vulnerabilities by considering the semantics of the reference value and ensuring that its values remain within the design intent of the application. Values that fail logical validation should be rejected.
Using Indirect References
An alternate approach to avoiding Direct Object Reference vulnerabilities involves embracing a design approach in which actual references to application-managed resources (such as ids, names, keys, etc.) are replaced with cryptographically strong random values that “map to” the original values. The mapping between the random values and their actual values is maintained on the server, so the application never exposes direct references. This is a more intrusive remediation than mere logical validation, as it impacts the application design.
Notice that due to the randomness of the published values, the use of Indirect References makes it very difficult to maliciously substitute meaningful values for references. Note that there will be a slight performance penalty to be paid for translating between internal and external references. Indirect references is often the preferred approach when a Direct Object Reference is actually sensitive information that should not be exposed, such as a loan number, a social security number, or an account id.
6. Prevention/ Protection against security misconfigurations
Follow these 8 measures to protect your application against security misconfiguration attacks.
a. Install latest updates and security patches. Have an easy to manage updating process with test environments to check updates before deploying to production environments.
b. Remove sample applications that ship with content delivery systems and web frameworks. Most tools that help build web applications include demo and sample code to help teach developers how to use the tools and starter toolkits. These apps are a known target for anyone attempting to compromise web application security.
c. Remove unused features, plugins and web pages. Only include the parts of web applications that you need for your services to end users.
d. Turn off access to setup and configuration pages. Don’t leave the setup and configuration pages available for external users.
e. Change usernames, passwords and ports for default accounts. Web application frameworks and libraries often ship with default administration names, passwords and access ports enabled. Everyone knows these. Change all these to non standard usernames, passwords and ports.
f. Don’t share passwords between accounts on Dev, Test and Production systems.
g. Don’t use the same administration accounts and settings across your Dev, Test and Production systems.
h. Turn off debugging so as to prevent sending internal info back in response to test queries or errors. Excessive debugging information can let attackers glean information about a web applications configuration.
7. CSRF Preventive Mechanisms
An attacker can launch a CSRF attack when he knows which parameters and value combination are being used in a form. Therefore, by adding an additional parameter with a value that is unknown to the attacker and can be validated by the server, you can prevent CSRF attacks
a. CSRF can be avoided by creating a unique token in a hidden field which would be sent in the body of the HTTP request rather than in an URL, which is more prone to exposure.
b. Forcing the user to re-authenticate or proving that they are users in order to protect CSRF. For example, CAPTCHA.
8. Broken Functional Level Remedies
a. The default should always be denial. Everyone should be denied access to everything, and then every specific role can be explicitly granted access for each function. It is also recommended to log all failed attempts as that can help discover if something is incorrectly configured.
b. Blocking all file types that should not be served anyway is a great way to prevent an attacker from accessing any forgotten configuration files, databases or log files that were mistakenly exposed to the internet without authorisation. Enforcing such blocking may not always be possible, but it is good to at least consider it.
Oditek as a leading Security Testing Services Company
Web applications are considered the most exposed and least protected, thereafter vulnerable because the standards somehow are not focused on security but more in the serve need functionality. Security threats are more common than before because the internet has become today’s economy most valuable tool for everyone. So there is indeed need to protect our resources, data and user privacy information. As technology move forward and brings new strategies, tools, models and methods to increase security levels, hackers will be part of this never-ending game. Regarding the penetration test we can conclude that web application security tools are a fundamental component in the security process but the known security vulnerabilities by their nature can be considered complex and created by real intellectual minds with the “code” word written in their forehead, this is why we need the best minds armed with great tools to eliminate these weaknesses in a cost-effective way.
Please reach out to us on security testing needs by sending an email to info@oditeksolutions.com
