In this article, we will get you introduce with a different types of attacks that may happen to users. It is the truth that some of those attacks have similarities with XSS attacks and can succeed in such situations where the plain XSS wasn’t possible. Also, the attacks against other user’s apps come in many forms and manifest a variety of subtitles and nuances which are frequently overlooked. Besides this all, these other techniques are much harder to understand. That is the main problem. Before we go further, I would recommend you to re-ask your knowledge about the internet security tips and cyber security tips, so you will understand what we are talking about better. Let’s go!
Inducing User Actions
We will here examine some additional methods which can be used even in the apps that are secured against XSS.
session riding is a kind of the attack which is closely related to session hijacking attacks, where the attacker captures a user’s session token and therefore can use the app as that user. Also, the attacker actually never needs to know the victim’s session token. He can just hijack it. Sound creepy, right?
We will now introduce you to preventing CSRF flaws. CSRF are those vulnerabilities which arise because of the browsers that automatically submit cookies with the additional methods of the tracking sessions. Also, it is submitted back to the issuing web server with each subsequent request. So, what would be the defense then? It sounds too complicated. We will try to make it simple for you to understand. Supplementing the HTTP cookies would be the standard defense against CSRF attacks. They should be supplemented with the additional methods of tracking sessions. It typically takes the form of the additional tokens which are transmitted through the hidden fields in the HTML forms.
UI Redress
As we have already said, an anti-CSRF defense which involves the tokens within the page aims to ensure that the requests made by the user originate from that user’s actions within the app itself. Also, that they are not induced by some third-party domain. How are the UI Redress attacks designed? They are designed in a way to allow a third-party site to induce user actions on the another domain, even if the anti-CSRF tokens are being used. If we look at the things in the relevant sense, this attacks can work. And why that happens? Well, because the resulting requests actually do originate within the app being targeted. These techniques are often referred to the terms and events like ”clickjacking”, ”stroke jacking”, or many other buzzwords.
This attack involves the attacker’s web page loading the targeted app within an ‘iframe’ on the attacker’s page. So, the attacker actually overlays the target application’s interface with a different interface provided by the attacker.
Preventing UI Redress
There is a more robust method for the app to prevent an attacker from framing its pages, and that is to use X-Frame-Options response header. This is a must because there are some kinds of frame busting code which may hinder UI redress attacks in some situations, but it is not a safe way. So, follow the first instruction we have said.
Capturing Data Cross-Domain
There is the same-origin policy designed to prevent the code running on the one domain from accessing the content which is delivered from a different domain.That is why cross-site requests forgery attacks which are often described as one-way attacks. But, one domain may cause the requests to a different domain and it may not easily read the responses from those sent requests for stealing the user’s data from a different domain.
So, the various techniques might be used in some situations to capture all or even a part of a response from a different domain. Such kinds of the attacks exploit some aspect of the target app’s functionality together with some feature of the popular browsers for allowing the cross-domain data capture in a way that the same-origin policy is intended to prevent
The data can be captured by injecting HTML or CSS injecting. It is already well-known that many applications contain the functionality which allows the attacker to inject some limited HTML into the response which is received by a different user in such a way that falls short of a full XSS vulnerability. When such a situation happens, it might be possible to leverage the HTML-injection condition to cause sensitive data within the page to be sent to the attacker’s domain.
What about the CSS injecting? Let’s show it in the example. In a web mail app, the attacker may be able to introduce some limited text into the response of the target through the subject line of an email. He can be also able to capture the sensitive data cross-domain by injecting CSS code into the app.
Besides those two attacks, there is also the JavaScript injecting. How to prevent that one? There are several preconditions which must be in place before the JavaScript attack can be performed. So, to prevent this attack it is necessary to violate at least one of the preconditions we will know the list.
1.The app should use the standard anti-CSRF defenses to prevent cross-domain requests from returning any of the responses which contain the sensitive data.
2.Sometimes the app dynamically executes JavaScript code from its own domain. In such a situation, a client-side code can use HTML or HTTP request retrieve the raw response and perform the additional processing on it before the script is executed.
3.And because of that, the app can use HTTP or HTML requests for receiving the dynamic script code, it can also use POST requests to do so.
Open Redirection Vulnerabilities
These kinds of the vulnerabilities arise when the app takes the user-controllable input and uses it for performing a redirection, instructing the user’s browser to visit a different URL than the one requested. These open redirection vulnerabilities are usually of much less interest to the attacker than the cross-site scripting. That is because it can be used to perform a much wider range of the malicious actions. It is the truth that the open redirection bugs are primarily of use in phishing attacks in which an attacker seeks to introduce a victim to visit a spoofed website and enter the sensitive details. It can lend the credibility to the attacker’s overtures to potential victims because it enables him to construct a URL which points to the authentic website he is actually targeting.
The first thing you can do to identify an open redirection vulnerability is to identify every instance within the app where a redirect occurs. So, better to prevent it, right? What can you do about it? Let’s see!
1.You need to remove the redirection page from the app, and also the replace the links to it with the direct links to the relevant target URLs.
2.Maintaining a list of all valid URLs for the redirection is also a must. You need to pass an index into this list, instead of passing the target URL as a parameter to the redirected page.
Local Privacy Attacks
There are the many users which access the web applications from a shared environment in which an attacker may have direct access to the same computer as a user. It gives rise to a range of the attacks to which insecure apps may leave their users vulnerable. It may arise in several areas, such as persistent cookies, cached web content, browsing history, autocomplete, flash local shared objects and silver light isolated storage.
Preventing Local Privacy Attacks
What the applications should do to prevent the local privacy attacks? They should avoid storing anything which is sensitive in a persistent cookie. Although the data may be encrypted, it can potentially be resubmitted by an attacker who captures it. Besides that, the apps should use the suitable cache directives for the prevention of the sensitive data being stored by browsers. Furthermore, the applications should never use the URLs for transmitting the sensitive data, because they are liable to be logged in numerous locations. All of those data should be transmitted using HTML forms which are submitted using the POST method.
Attacking ActiveX Controls
These controls are of the particular interest to the attacker who targets the other users. Once when the app installs a control for invoking it from its own pages, the control must be registered as ‘safe for scripting’. And after that occurs, basically any other website accessed by the user can use that control. The ActiveX controls are typically written in native languages such as C/C++, and they are at risk from classic software vulnerabilities (buffer overflows, integer bugs, format string flaws…).
So, how to find the ActiveX vulnerabilities? The app alerts when the application installs ActiveX controls, asking for your permission to install it. We can explain to you how to recognize it best if we compare it to the HTML code sources.
Okay, we saw that, now what to do and how to prevent those vulnerabilities?
1.There is a security-focused source code review and presentation test. Those should be carried out on the control for locating the vulnerabilities such as buffer overflows.
2.Also, the control line shouldn’t expose any inherently dangerous methods which call out to the filesystem or operating system using user-controllable input. There are always safer alternatives. So, for example, if you need to launch external processes, you should compile a list of all the external processes which may legitimately and safely be launched. Well, creating a separate method each one or use a single method which takes an index number into its list is a proper way to handle things.
Attacking the Browser
This category of the attacks against the users doesn’t depend on the behavior or specific app. These attacks rely solely on features of the browser’s behavior, or even on the design of the core web technologies themselves. They can be delivered by any malicious website or by any benign site that has itself been compromised already. So, they lie at the edge of the scope of a book about hacking web app. But not to forget, they are worthy of brief consideration partly, and that is because they share some features with the attacks which exploit app-specific functions. Also, they provide the context for understanding the impact of the various app behaviors through showing what is possible for the attacker for achieving even in the absence of any app-specific flaws.
Man-in-the-Middle Attacks
Is there anything more surprising than some serious attack which can still be performed even if the app uses the HTTPS for all the sensitive data is safe? And when the targeting user always verifies that HTTPS is being used properly?
Sadly, it actually exists. These are the attacks which involve an active man in the middle. We talked about the passively monitoring, but this is not a case in this attack. It is the type of the attacker which changes some of the traffic on the fly. It can be delivered in numerous common situations, even including the wireless hotspots and also shared office networks, and by suitably minded governments.
So, what we have learned today? This article was a bit longer, I agree. But we wanted to cover everything you need to know about this topic. I believe that I was very clear and explained everything you need to know about these topics. We examined a huge variety of ways in which defects in a web app can leave its users exposed to various malicious attacks. There are many of those vulnerabilities which are so complex for the understanding and sometimes even very hard to discover. The great amount of the investigation is needed to explain all of these attacks and to understand them. The better way is to prevent them, right? But how could we prevent them, if we do not understand them truly in the first place? But don’t worry about that, we are here to provide you all the quality information you need to know. So, keep reading and keep yourself safe! Hope you like our article!