1. SQL Injection Prevention TechniquesCommonly 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 managementPassword 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.
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”.
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.
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 exposurea. 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 TechniquesTo 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:1Never 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:2When you want to put untrusted data directly into the HTML body somewhere. This includes inside normal tags like div, p, b, td, etc
Rule:3Attribute 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 -
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 referencesThere are two strategies for avoiding Insecure Direct Object References, each is explained below:
1.Logically Validate References
2.Use Indirect References
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 misconfigurationsFollow 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 MechanismsAn 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 Remediesa. 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 CompanyWeb 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 email@example.com
What OdiTek offers
Refer our Skills page:
We had a tough deadline to launch our .Net based application that processes a lot of data, and got very frustrated with our development agency we hired. Fortunately we got Oditek, and they took over seamlessly the product development, launched the app & continued feature development. Just awesome!
They were very attentive to our needs as clients and went out of the way to make sure our projects were taken care of. They were always able to get projects done in the specifications we requested. They are passionate about getting things done; I would definitely recommend them to lead any IT projects.
I worked with OdiTek on few high profile banking application projects. They did a fantastic job with web applications & manual testing on the VAS apps for two leading banks of UK that included rigorous UAT phases. I recommend them for any application development where security matters.
OdiTek is our extended team who works on our key software projects. They are dependable, good in collaboration and technically very much to the level what we expect a global team should be. They had transformed our web applications, CRM and added mobility to existing business platforms here.
It's been more than 4 years now that we are working with OdiTek on our cloud based web product development. It's been amazing working together, they are very competent on designing scalable, high performance apps. Their technical support is outstanding to say the least, even at odd hours.
I am a fan of Team OdiTek since 2014 and have worked on many product development projects together. Specially worth mentioning their deliveries on VAS Banking web application development & manual testing services for Smarta, UK. They are highly skilled & a professional team to work with.
OdiTek has been working on our Integrated Web-scale Mobile Platform i.e. Optimal Health since 2014. They are very professional and takes care of the requirements meticulously. They are technically very sound and sincere in ensuring quality & performance. Wonderful working with them!
You can trust the team, with minimum supervision you get the work done. They are honest, professional & committed to schedule & quality. I had been successfully running 3 business applications designed, developed and maintained by Oditek developers. It’s been a pleasure working with them.
OdiTek has been working in custom software development, including services for test automation. Many of them have worked with me in 2009-10 when I was R&D Manager in NetHawk India. They have great enthusiasm & a passion to excel in bringing customer success. Their work has been very impressive.
It's amazing to see these guys are turning their experience into a global delivery excellence at OdiTek. I am sure their past large scale product development experience will be handy to product companies. I would always recommend Oditek for software development, especially performance-driven solutions.