There is something i wonder. I am giving an example of XSS. We say it is divided into 3 types. Blind, Reflected and stored. There is no one who does not know reflected and stored. We say that the attacker is not informed about the vulnerable with a blind at the beginning of it's name, but if there is no information, how does the attacker understand that there is any vulnerable?
Thank you from now.
In blind XSS the attacker typically doesn't know if his attack will succeed at first.
You can think of it like setting up a trap. You don't know if it will succeed, or if the victim has protection, you are blind.
Actually, blind XSS vulnerabilities are a variant of stored (persistent) XSS vulnerabilities. The attacker's input is saved by a web server and then executed as a malicious script in another application or in another part of the application.
For example, an attacker injects a malicious payload into a contact/feedback form and POST it (setting up a trap). Let's say the info sent is then served by another application or in another part of the app:
The admin is opening his admin panel/dashboard to view feedback from his users. When the administrator of the application is reviewing the feedback entries - the attacker’s payload will be loaded and executed.
The attacker was blind - he didn't know if the server side of that form sanitize the input, or if the "admin panel" of the application has any protection against JS execution.
Example of web applications and web pages where blind XSS attacks can occur:
Contact/Feedback pages
Log viewers
Exception handlers
Chat applications / forums
Customer ticket applications
Web Application Firewalls
Any application that requires user moderation
In the case of blind XSS, the payload can be executed after a long period of time when the administrator visits the vulnerable page. It can take hours, days, or even weeks until the payload is executed.
Therefore, this type of vulnerability is much harder to detect compared to other reflected XSS vulnerabilities where the input is reflected immediately.
Related
I did a small sample test and found that almost all web sites I tested suffer from the vulnerability where I can access restricted pages (ie pages that require logging in) even after I have logged out from the browser if I save the cookies while I am still logged on.
The test was fairly simple. I just replayed a web request in Fiddler after I had logged out from the browser. For example, with outlook.com, after logging out, I could replay the page that shows the address book and still get my contacts' email addresses.
May I know what the industry standard is regarding this as I have one customer who insists on fixing this vulnerability but not wanting to increase the hardware specs.
I'm not sure if there's an industry standard, but there are best practices. And the best practice is to clean the cookies, and cookie management.
You shouldn't have to worry about hardware on this either. It's a simple lookup to see if a value is valid. If it isn't, then the session state shouldn't get resurrected.
Again, I would use HttpOnly and a secure flag on the cookie. That way, it will limit replay attacks more. And when it comes to resurrecting sessions, make sure that session files are destroyed on the server, not just abandoned.
Abandoned sessions mean they can potentially be resurrected.
Hardware will generally not be an issue with this problem. If it is, then look at your solution, as there might be a better way.
This isn't a language specific question, but I am using PHP5.
I am working on a project that has some amount of PII. Legally we are required to secure this data from hacking attempts, and because of that I have been researching best practices for defending common attack types. Obviously all database calls are using parameterized queries, and all data provided by the user is sanitized to prevent injection. I have also implemented sessions and methods to prevent session hijacking.
When it comes to defending against XSS attacks on forms, best practice seems to be to include a hidden input with a form token, then after the post to check the tokens match. There are further ways to make this more secure.
I have imagined one type of attack and haven't found a solution for it. What if a malicious site loads a hidden iframe pointed at my site (eg, view-member.php?id=1234) and because the victim user is logged into my site, their session continues in that iframe. What is stopping this malicious site from iterating through the IDs and ripping the data to get ahold of PII? Should I be creating a unique token for each page view, and checking that token when the page loads?
I am not 100% sure, but assuming my site is using HTTPS, the browser should warn the user and/or prevent the connection. Is that correct? Is that enough security?
In fact, everytime you present a form or any kind of interaction, you should include a randomized, verifiable piece of information that changes every time. This is not for preventing XSS but CSRF: https://en.wikipedia.org/wiki/Cross-site_request_forgery
The main problem is: An attacker can just send automated requests to your input-handling script without going through the "pain" of filling in your form manually (or even visit your page).
However, you won't prevent XSS attacks with this technique, as XSS attacks are mainly user input containing executable code (javascript) that is not filtered by the input validation. So to prevent XSS as well, you should always make sure not to deliver unfiltered user-generated content anywhere.
HTTPS won't help you in either case unless you use client-side certificates that allow access to your website only from trusted clients. HTTPS mainly acts as a transmission scrambler and identity verifier but does not prevent a bot from sending valid (but malicious) data to your form.
Hosting a website in an iFrame does not grant the attacker the permission to read cookies or information from the target page (that would be awful) as long as you follow the same-origin policy: https://en.wikipedia.org/wiki/Same-origin_policy
With this, only domains you whitelist will get access to information hosted on your page.
Vaadin and Eclipse RAP/RWT are web application frameworks with - as far as I understand - similar architecture. My question is if an application built with Vaadin or RAP is prone to denial of service attacks? I am currently evaluating the frameworks and want to be sure that this is not a concern.
Here is my reasoning:
With Vaadin or RAP you don't build HTML output but instead construct a Widget tree similar to an Swing/SWT application (in case of RAP it is SWT). The frameworks renders the widget tree as HTML in the browser, and sends user interactions back to the server, where the application gets notified in terms of events. The events are delivered to listener objects, which have previously been registered on widget.
Therefore the widget tree must be kept in some sort of user session and of course consumes some memory.
If the application is public (i.e. does not sit behind a login page), then it seems that there is a possible denial of service attack for such an application:
Just fire requests to the apps landing page, and probably fake a first response. For any such request, the framework will build a new widget tree, which will live some time on the server, until the session expires. Therefore the server memory should be filled with tangling users sessions very soon.
Or did these frameworks invent protection against this scenario?
Thanks.
A framework only can not protect you from DoS attacks.
Vaadin has some features built in to prevent attacks, but of course these features depend on how you code your application.
There is a long webinar about vaadin security:
https://vaadin.com/de/blog/-/blogs/vaadin-application-security-webinar
Vaadin does some validation of the client<->server traffic
to prevent XSS and other attacks.
But when you do some special things, you can open doors for such attacks.
As for the scenario you described:
The initial vaadin session takes some memory on the server (Just as all other sessions on any server)
How large this memory footprint is, depends on the initial number of widgets and what you load in memory for this. (DB connections etc.)
Usually this is not a problem when you have a very lightweight login page
But if you display large tables and many other fancy things, then you will have to have enough memory for the number of requests. (The same apply to all othe http servers/applications, they also need memory for this)
If the number of requests surpasses the capacity of your server, any web service can be brought down in a DoS attack
EDIT:
Due to good points in Andrés answer I want to sharpen my question.
First of all, of course I agree, if you put an application behind a login-wall
then the DOS-threat is not that big. At least you can identify the attacking user. And the login page itself can
be lightweight or even must not be implemented with Vaadin/RAP.
And as Vaadin/RAP applications are most likely used in RIA-style intranet settings then the DOS scenario does not invalidate
their use in these settings.
But at least both frameworks itself expose demo pages without logins on the internet:
See http://www.eclipse.org/rap/demos/ and http://demo.vaadin.com/dashboard/
These are not simple pages, and probably use quite a bit of memory.
My concern is about such a scenario, a non access-restricted internet page:
Once these frameworks responded to a request, they must keep serverside memory for that request for quite some time
(say the classical 30 minutes of a HTTP session, at least in minute scale).
Or to express it differently, if the application retains memory per intial user request for some substantial time it will be
prone to DOS attacks.
Contrast this with an old-style roundtrip web application which does not require user identification.
All the information needed to decide what to return is contained in the request (path, parameters, http-method, ...),
so a stateless server is possible.
If the user interacts with such an application, the application is still free to store session-persistent data on the client
(shopping cart contents in a cookie, etc.).
Recently i was studying about the XSS attacks and how devastating they can be on a website.
What surprised me was that, web (even SO) is full about how to prevent xss attack but there is no relevant resource on how to recover a website, after it has been attacked through xss.
There are some things which i came across like :
upload the backup website code back on server
download the entire site and manually look for any malicious script
but these doesn't sound good enough....i mean, isn't there any other professionaly active method to recover the sites once hacked???
With XSS the code is not actually modified. Instead what usually happens are one of two scenarios: reflected and stored XSS.
In reflected XSS, there is some parameter in the request (usually a query string parameter) that gets echoed onto the page without being sanitized. This could lead to an attacker providing a malicious link to a user, and them clicking and having their session hijacked.
In stored XSS, the attacker finds some way to persist a malicious string (usually stored in a database, in the form of a forum post or website comment) that other users will come across when viewing this site. That script is then executed in the context of the user that viewed the page, and the attacker could again hijack the session.
To "recover" from reflected XSS - you would want to fix the reflected parameter (do something like output encoding) and invalidate all sessions, making users have to log in again.
To "recover" from reflected XSS - you would want to identify where the malicious code was provided, add sanitization of the input and encoding of the output of that data. Then clean the database of these malicious values, then invalidate all sessions, forcing users to log back in again.
#Stefan_H got it right. (+1)
Indeed you only need to recover from stored XSS.
However, what you also need to consider, is that store XSS attack is often just a symptom of the actual illness.
Simply put, to execute such XSS attacks, an attacker must have high-level access to your website/server resources. This means that - besides the malicious XSS code - your site also holds a backdoor shell which allows the attacker that level of access.
And so, in fact, you don't need to recover from XSS but from the backdoor shell. Failing to do so will allow the hacker to re-inject your site, even once the code was sanitized.
Some backdoors exist on a site level, others will affect whole servers. The type of control they provide will vary but - in most cases - they will allow total access to most website resources. This will lead to:
XSS and other malware injection
Hijacking the site/server for the purpose of DDoS (joining a Botnet)
Data theft
Eventual defacement
To prevent re-occurring attacks you`ll need to:
Use some very early backup (you don't know how long the backdoor was present in your file system)
Better yet, use some kind of backdoor detection tool (there are some free ones but few are actually good)
Understanding how the shell got there in the 1st place (RFI and password hacks are the two prime suspects)
GL
Hi an XSS attack is treated as an attack from the client's machine. But is there any way to make an XSS attack over the server ?
I want to know is there any way to execute a code on the server using the client side interface like in the case of SQL Injection, but here it is not the Database Server but a Simple Web Server or an Application Server.
Sometimes, it's also possible to use XSS as a vector to trigger and leverage Cross-Site Request Forgery (CSRF) attacks.
Having an XSS on a website is like having control on the javascript a user will execute when visiting it. If an administrator stumbles upon your XSS code (either by sending a malicious link or by means of a stored XSS), then you might get him or her to execute requests or actions on the webserver that a normal user usually wouldn't have access to. If you know the webpage layout well enough, you can request webpages on the visitor's behalf (backends, user lists, etc.), and have the results sent (exfiltrated) anywhere on the Internet.
You can also use more advanced attack frameworks such as BeEF to attempt to exploit vulnerabilities in your visitor's browser. If the visitor in question is a website administrator, this might yield interesting information to further attack the webserver.
XSS per se won't allow you to execute code on the server, but it's a great vector to leverage other vulnerabilities present on the web application.
Vulnerabilities like XSS or SQL injection are specific instances of a more general problem: Improperly concatenating attacker-controllable text into some other format (eg, SQL, HTML, or Javascript)
If your server runs any such format (eg, eval()), it can have similar vulnerabilities.
The answer to your question is not entirely straightforward.
Specifically, no you cannot attack a server using XSS by by injecting code through its interface.
However, there are ways to "inject" code into the server through its interface and have the server run it. The techniques vary widely and substantially, and are highly implementation dependent.
For example, there was a web application that allowed users to upload image files for display. The web application had code that "touched up" the image. There was a vulnerability in the touch up code. A malicious user uploaded a carefully prepared, malicious .jpg file that overflowed a buffer in the code and shoveled off a shell to the attacker's machine. In a case like this, the attack was conducted by "injecting" code into the web app through its interface.
As long as you never process user input (other than storing it in the DB and returning it to other users), then you should be pretty safe from this type of attack. Probably 99% of web apps need to be much more worried about XSS attacks from users to other users than from code injection attacks against themselves.