A1 Injection vulnerability is currently ranked #1 on the OWASP Top 10 chart which means that it is responsible for a largeportion of public disclosures and security breaches.
So what is an injection vulnerability? Well, there are actually several types. Some of the most common types include SQLinjection, code injection and LDAP injection. With the different types of injection, the attacker will construct his attack in a different way.
SQL is an structured Query language that enables interaction with database servers. SQL commands such as INSERT, RETRIEVE, UPDATE, and DELETE are used to perform operations on the database.
SQL injection is a technique which attacker takes non-validated input vulnerabilities and inject SQL commands through webapplication that are executed in backend database.
Here an attacker could enter into network without providing any Authentication and gain highest privilege.
After attacker enters into the network, he will get access to sensitive date stored in the network.
Compromised data Integrity:
Attacker changes content of website by entering malicious contents.
Compromised Availability of data:
Using this technique attacker will delete sensitive and crucial information from database.
Remote Code Execution:
An attacker could modify, delete, or create data or even can create new accounts with full user rights on the servers that share files and folders. It allows an attacker to compromise the host operating system.
A1 Injection vulnerabilities also present some of the most significant risks when effectively exploited. Some of these risks include:
- Data loss or corruption
- Data theft.
- Unauthorized access.
- Denial of service.
- Complete host system takeover.
SQL QUERY Vulnerable to attack:
select count (*) FROM Users WHERE UserName=’ ” + txtUser.Text + ” ‘ AND passwords=’ ” + txtpassword.Text + ””’;
Similarly a blind text in framework make the framework vulnerable.
Query HQLQuery = session.createQuery(“FROM accounts WHERE custID=’“ + request.getParameter(“id”) + “‘”);
Understanding SQL Injection:
http://mydomain.com/test?Id=1 ↓ SELECT * FROM test WHERE ID = 1
Under normal circumstances it will probably translates down to SELECT * FROM test WHERE ID= 1 , there might be a table named test and it simply saying select ID no.1 from the table. We need to look over here for different class of information.
Trusted data http://mydomain.com/test?Id Untrusted data 1
The first part we need to see here is what is trusted data (http://mydomain.com/test?Id) and the un-trusted (1), the unstruted is the one which vulnerable to attack.
Now what happens if an attacker appending the condition http://mydomain.com/test?Id=1 or 1=1 if this condition passes through database then the login is going to change, instead of pulling a single ID it will pull the entire database.
- Whitelist untrusted data
- What does we need trust?
- Does it adhere to expected patterns?
2. Parameterise of SQL Statements
- Separate the Query from the input data.
- Type cast each operator.
3. Fine tune DB Permissions
- Segment accounts of admin and public.
- Apply “the principle of least privilege”.
Broken Authentication and Session Management vulnerability allow’s attackers either to capture or bypass the authentication methods that are used by a web application. Impact would be severe as attacker can able to login account as normal user.
When visiting a website to access your information, you need to log in. To get past this point, you need to provide the
correct Username and Password values.Once you submit this information, a unique value called the Session ID is generated, which is linked to your credentials to keep track of you while you are logged into the application. This value is usually a string of random letters and numbers as seen at the bottom of the slide.
Possible ways of webapplication failure
- Unencrypted connections.
- Encourage users to have strong passwords.
- Expire sessions Quickly.
- Implement login rate limiting,lockout’s and Hashing passwords.
- Session ID’S used in the URL.
If the connection being used between you and the web application is not encrypted, anybody can see the data being
transmitted.This means that ALL INFORMATION that you are sending and receiving between you and the site can be intercepted without your knowledge.
Fails to protect the user name,password, sensitive details and session ID’s.
By enabling encryption on requests that contain sensitive data can prevent this information from being intercepted by attackers.
Encourage users to have strong passwords
Weak username and passwords are easily guessed by attackers to get unauthorized access.
We can prevent the weakness by enforcing users to have strong passwords.
Expire sessions Quickly
Application does not discard session after certain amount of time or even after logging out.
Invalidate the session ID after pre-determined time or upon logout.
Implement login rate limiting,lockout’s and Hashing passwords
If stored passwords are stolen by unauthorized individual, if no protection is given and values would be visible in plain text.
To prevent weakness stored password should be salted and hashed in addition to encryption.
Session ID Used in URL
Session ID value is transmitted in the URL where attacker can see that, which fails to protect session ID value.
To prevent the weakness Make sure the sensitive information is sent in the body part of the post request.
Let's take a look at the example URL: http://192.168.242.137/login.jsp?sessionid=abc12345df
Along with this we conclude our coverage with A2-Broken Authentication and Session Management.
XSS is a very commonly exploited vulnerability type which is very widely spread and easily detectable.
- Reflected XSS
- Stored XSS
- DOM-Based XSS
In Reflected XSS, an attacker sends the victim a link to the target application through email, social media, etc. This link has a script embedded within it which executes when visiting the target site.
In Stored XSS, the attacker is able to plant a persistent script in the target website which will execute when anyone visits it.
With DOM Based XSS, no HTTP request is required, the script is injected as a result of modifying the DOM of the target site in the client side code in the victim’s browser and is then executed.
http://test.gbhackers.com/search?q=gbhacker Searched for <strong>gbhacker</strong> alert(document.cookie)
Imagine that we are having an URL like this and we are searching for gbhacker and it will reflect following query in the browser. We trust the domain and we trust the resource being entered in search page, so now the untrusted part gbhacker was the query string entered by browser, the attacker can manipulate the value anything as they like, for an example they change like this alert(document.cookie).This is just a simple query to popup an alert in the webpage, if some requested the page of attackers website and passed document.cookies as parameter in website then attacker can gather all cookies in the website.If they got Auth cookiesthey cansimply hijack user sessions.
Potential risks about XSS
The attacker can compromise or take over the victim’s user account in the application. They could retrieve data from the target web application, modify content on the target page,redirect the victim to another malicious or spoof site, or use it as a platform to install other malware on the victim’s system.
The consequences of any of the above can seriously impact your ability to conduct business, your customers, and your organization’s reputation.
Defenses against XSS
- What input do we trust?
- Does it adhere to expected patterns?
- Never simply reflect untrusted data.
- Applies to data within our database too.
- Encoding of context(Java/attribute/HTML/CSS).
Insecure Direct Object References prevalence are quiet common and this risk can be easily exploited, anyway the impact of risk would be moderate.
Here is the sample scenario, we are having a attacker, webserver and a Database.Here what the attacker to do is simply changing the ID in the URL, now the website saves the request and it goes to database and fetch different record than the permitted for the user. If the Insecure Direct Object References issuccessful then the database passes request to the website and data provided to the attacker.
UNDERSTANDING DIRECT OBJECT REFERENCES
In this example an legitimate user asking for account balance, so hitting a balance resource and a query string(ID=) , now take the other user’s they are hitting the same URL and the only difference is the account ID.
Here is the thing about these URL’s ID=(this is untrusted data),this query string value has been easily manipulated that any one of the user can change the account ID and fetch the balance of other users.In the system we need to implement validation, if the users manipulates the request,they will not be permitted to unauthorized area.
- Implement access controls, be explicit about who can access the resources.
- Use Indirect reference map, Don’t expose internal key’s externally.
- If possible map them to the temporary one’s.
- Avoid predictable keys, (Incrementing integers and Natural keys are discoverable).
Security Misconfiguration prevalence are quiet common and this risk can be easily exploited,anyway the impact of risk would be moderate. It completely depends upon how bad the security Misconfiguration is, it narrow downs the attacker to gain access to unsecured area(Insecure weblogs,Internal error,Insecure admin page).
With this risk the website exposes the sensitive data which act’s as a gateway, which attacker may use to exploit the server in future.
Understanding Server Misconfiguration
- Is any of your software out of date? that includes OS, Webb/App server, Databases,Applications and all code libraries.
- Any unnecessary features enabled or installed?(Ports, Services, Pages,privileges).
- Are default account’s and password still enabled/unchanged?
- Does your error handling mechanism reveals stack traces or other informative error messages.
- Are the security settings in your development framework and libraries are not set to secure values.
Am I Vulnerable To ‘Security Misconfiguration’?
Is your application missing the proper security hardening across any part of the application stack? Including:
- Is any of your software out of date? This includes the OS, Web/App Server, DBMS, applications, and all code libraries (see new A9).
- Are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)?
- Are default accounts and their passwords still enabled and unchanged?
- Does your error handling reveal stack traces or other overly informative error messages to users?
- 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.
How Do I Prevent ‘Security Misconfiguration’?
The primary recommendations are to establish all of the following:
- A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically (with different passwords used in each environment). This process should be automated to minimize the effort required to setup a new secure environment.
- A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment. This needs to include all code libraries as well (see new A9).
- A strong application architecture that provides effective, secure separation between components.
- Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches.
Example Attack Scenarios
Scenario #1: The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.
Scenario #2: Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she decompiles and reverse engineers to get all your custom code. She then finds a serious access control flaw in your application.
Scenario #3: App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide.
Scenario #4: App server comes with sample applications that are not removed from your production server. Said sample applications have well known security flaws attackers can use to compromise your server.
- Harden the installation(Turn off unwanted features, Apply principle of least privilege).
- Tune the app(Ensure it’s production ready, Defaults are not right).
- Ensure packages up to date(Be conscious on third party tools risk, Have a strategy to monitor and update)
Examples of mitigating the Risk
Detecting privelance of security mis-configuration, what we are going to use is a Google dork and the search results for Elmah (Error Logging Modules and Handlers) this is a very popular third party library for capturing and logging error’s and only administrators can have access to it.
With a carefully crafted Google search query inurl:elmah.axd “error log for” we can get unsecured results which vae database passwords, Authtokens. Hope-full it demonstrates how easy to mitigate the risk and execution.
Sensitive Data Exposure is difficult to exploit wheres prevalence and detect-ability is less common, but the impact is severe. Clearly if some sensitive data is leaked it will cause a severe fall out.
Here we have a user login’s into a website over HTTP which has no encryption, in this case attacker can get into the network and sniff the traffic which is also called as Man in the middle attack(MITM). Then attacker can clearly gain access to any of the data going over the connection.So they can easily retrieve user’s password, also the attacker can manipulate data sent over http.
Understanding Sensitive data Exposure
- Insufficient use of SSL (Login page with http,Mixed mode,Cookies not sent securely).
- Bad cryptography (Incorrect password usage,Weak algorithm,Poor protection of keys).
- Some other risks (Browser auto-complete,Disclosure via URL,Leaked logs).
- Minimize sensitive data collection(Reduce the window for storage).
- Apply HTTPS everywhere (Login pages and everything should be https).
- Use Cryptostorage for passwords (Use hash algorithms designed for password,Secure key Management).
Function Level Access Control can be exploited easily, if there is an missing access control on resource control, exploiting the risk is simple as plugging the URL in browser. Privelance is very common, whereas the detect-ability ratio is Average and impact is Moderate.
Let’s imagine this user is Authenticated as admin, so he making an Authenticated request to the server, and once the server responds this user will have a navigation link in browser for admin. Now if the attacker requested the admin, unfortunately sometimes websites itself return the admin page.
So why it’s the missing function of access level, this is the specific case OWASP talks about. Within the presentation layer only security trimming in place, however the resource behind the link have no access controls.
Understanding missing function Level access controls
- Does the UI show navigation to unauthorized functions?
- Are server side Authentication or authorization tokens missing?
- Are the server side check done solely rely on information provided by the attacker?
- A system or diagnostics resources accessible without proper authorization?
- Will forced browsing disclose unsecured resources?
- Define a clear authorization model, centrally and consistently.
- Use roles and then apply memberships.
- Check for default framework and resources.
- Check forced browsing with Automated scanners.
- Capture and replay privileged requests.
- Include post request and Async calls.
Cross Site Request Forgery is one of the most common form of attack by online spammers and scammers. Exploicity of this attack is bit complex, it’s prevalence is common.
But CSRF attacks can be predicted easily and their impact is moderate.
In this scenario we are having an Attacker, User, Attacker’s and Target server. Attacker can share the malicious link to user’s through Multiple ways.
Link sharing can be done through Social Media, Email and with many of different ways. Once the User click’s on the link, then the link goes to the attackers webserver.
Now the request from attackers server also carries the Embedded Malicious request, which causes the user browser to issue a request to the target website.
Entire process of CSRF is to get the authenticated user, who is already authenticated to the target website. So that’s one of the condition normally need to meet for successful CSRF.
Cross Site Request Forgery
In this scenario we are having an user transferring money on a banking website, now the user login to bank and to make Authenticate money transfer request.
The request should be like this HTTP POST http://bank.com/transfer, once the request processed then in-order to persist the user state server will sent an Authcookie : 86GHTR.
Being the post request there is a request body which consist of Target Account number : 7895457898054 and where the money Amount : 100000 is to transfer.
Now the attacker can forge this request and he is the rub with CSRF, if the attacker can trick the user’s browser in making this request when I may be able to successfully execute a CSRF request.
So now does an attacker execute that: Attacker alreadyaware of the HTTP post path, they look at the bank and tell what’s the URL that you need to post to transfer money.
They already aware of the fields, so they only require the URL and request body, because if they get the user to make a request to that part with the request body.
Then the Auth Cookie will be sent automatically with the request which browsers normally do, send any cookie with the request valid for a target domain.
Cross Site Request Forgery Defenses
- CSRF is exploited if we use predictable patterns.
- Employ Anti-forgery tokens, add randomness to the request.
- Valid request should not originate externally.
- The referrer should be in each header requests.
- Native browser defenses.
- Fraud detection patterns.
Exploitability of the risk is average, Attacker needs to identify the weak part through scanning or manual analysis.
But the risk is widely spread, Many application has these issues on the grounds that most development teams don’t concentrate on guaranteeing their parts/libraries are breakthrough.
Most of the time, the developers don’t know every one of the parts they are utilizing, it doesn’t mind their formats.
A full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could range from minimal to complete.
Now the attacker and the webserver, the attacker tries to exploit a vulnerable component on the server, a Vulnerable component is nothing but a product or Library which could be at risk.
- In this scenario, the attacker tries to make a request to the website, and let’s assume this request loads a page which has the vulnerability.
- The website responds to the request which also discloses the vulnerable components.
- Once the attacker finds the vulnerable components and version, then he will go to Internet and searches for known vulnerabilities.
- Regardless it is easy to find risks associated with vulnerable components on the web, so the attackers get information on how this risk might be exploited.
- Then attacker so goes and launches the attack with the website.
- Identify Components and versions.
- Components that are used unplanned.
- Monitor CVEs impacting those components.
- Keep Components updated.
- Regularly Monitor new releases.
Web applications often redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages.
Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to use unauthorized pages.
Sometime, your application may need to redirect to another area by sending a redirect header to the customer in an HTTP response.This method found in applications that divert after an successful verification.
The redirection will be in the login form or the URL. both of which can be messed with by the client.Such redirects may attempt to install malware or trick victims into revealing passwords or other delicate data. Risky forwards may permit get to control bypass.
Developers can prevent the weakness by approving client input and furthermore confirming the URL being referred to is really an endorsed target URL.
You can use a guide map technique where URLs are mapped to names, for example, landing page, item pages, or stock page. This would keep clients from providing an invalid URL.
How to check for invalidated Redirects and Forwards?
- Spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they seem to be a target URL or a piece of such a URL. If so, change the URL target and see whether the site redirects to the new target.
- Check the code for all users of redirect or forward (called a move in .NET). For every use, distinguish if the objective URL is incorporated into any parameter values. Provided that this is true, if the objective URL isn’t approved against a white list, you are vulnerable.
- If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and test those that do.
How to Test?
This vulnerability occurs when an application accepts untrusted input that has an URL value without sanitizing it.
This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.
Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
A phishing attack example could be the following:
If the application uses forwards to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful.
In this case, the attacker crafts a URL that will pass the application’s access control check and then forwards the attacker to administrative functionality for which the attacker isn’t authorized.
Impact on Website
• Lack of End User Trust
• Lack of Credibility
• Malware Installation
• Worm Infections
- Destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
- Simply avoid using redirects and forwards.