Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws.
Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover.
The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries. Checking the code is a fast and accurate way to see if the application uses interpreters safely. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Penetration testers can validate these issues by crafting exploits that confirm the vulnerability. Automated dynamic scanning which exercises the application may provide insight into whether some exploitable injection flaws exist. Scanners cannot always reach interpreters and have difficulty detecting whether an attack was successful. Poor error handling makes injection flaws easier to discover
Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.
Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.
Consider the business value of the affected data or application functions. Also consider the business impact of public exposure of the vulnerability.
You may be vulnerable if:
1. User authentication credentials arenít protected when stored using hashing or encryption.
2. Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
3. Session IDs are exposed in the URL (e.g., URL rewriting).
4. Session IDs are vulnerable to session fixation attacks.
5. Session IDs donít timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, arenít properly invalidated during logout.
6. Session IDs arenít rotated after successful login.
7. Passwords, session IDs, and other credentials are sent over unencrypted connections.
XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are two different types of XSS flaws: 1) Stored and 2) Reflected, and each of these can occur on the a) Server or b) on the Client. Detection of most Server XSS flaws is fairly easy via testing or code analysis. Client XSS is very difficult to identify.
Attackers can execute scripts in a victimís browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the userís browser using malware, etc.
Consider the business value of the affected system and all the data it processes. Also consider the business impact of public exposure of the vulnerability.
Applications frequently use the actual name or key of an object when generating web pages. Applications donít always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.
Such flaws can compromise all the data that can be referenced by the parameter. Unless object references are unpredictable, itís easy for an attacker to access all available data of that type.
Consider the business value of the exposed data. Also consider the business impact of public exposure of the vulnerability.
The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider: 1. For direct references to restricted resources, does the application fail to verify the user is authorized to access the exact resource they have requested?
2. If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?
Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.
Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.
The system could be completely compromised without you knowing it. All of your data could be stolen or modified slowly over time. Recovery costs could be expensive.
The system could be completely compromised without you knowing it. All your data could be stolen or modified slowly over time.
Is your application missing the proper security hardening across any part of the application stack? Including:
1. Is any of your software out of date? This includes the OS, Web/App Server, DBMS, applications, and all code libraries
2. Are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)?
3. Are default accounts and their passwords still enabled and unchanged?
4. Does your error handling reveal stack traces or other overly informative error messages to users?
5. Are the security settings in your development frameworks (e.g., Struts, Spring, ASP.NET) and libraries not set to secure values?
Without a concerted, repeatable application security configuration process, systems are at a higher risk.
Valency Networks is a very agile, friendly and fun loving atmosphere and yet we maintain a cutting edge technical vibrant work environment.