Read also the
WikiPedia about CSRF.
It is in fact simple, but not easy to understand:
- You are logged in in a site: eg your local PC with XOOPS.
This means that every request the browser makes to the server with XOOPS, will be trusted and executed.
If that was not the case you would have to provide your login with every operation.
- If you surf in another tab or window to this evil site, it can trick the browser to send a request to the XOOPS site and doing there some things.
You won't notice, because you didn't here on this site either. When people speak over a page load of a website, then they think it as of one single operation.
For the browser it is not: it loads the html, the js and css files, the jpg's, png's flashes, audio, etc. For each of them, it is possible that the website makes one or more redirects. (eg That image? No longer here, ask there!) It could take dozens of requests, before the browser has assembled a page. And by the nature of the internet, these requests could go anywhere, to other sites on the internet.
As I said, nobody would notice, if one of the requests was going to your XOOPS or other targetted site. But it is your browser, that make the request and the other window is logged in, so the bad request operates under the same privileges.
Also the hacker on the evil site won't notice. Of course he knows, his page was accessed, but he won't know if the request succeeded or not. Eventually, he could see the result of his action on the targetted site.
I'm affraid that News or all other modules or even the core itself is not resistant against CSRF.
So why they listed specific this News /news/admin/index.php?op=newarticle link as vulnerable?
I think because it violates the W3C directives that a GET request of the browser should not have permanent changes on the server and its site. To cure this, there should be a split up of the operations (by the op parameter) in GET and POST requests. Now they are treated the same. Of course POST may do everything, but the GET should be limited to the operations that do listings, etc, but no permanent changes.
This may break the module if some of the operations are effectively also done by ordinary links from generated code or in templates (= GET requests). These have to be recoded then to forms.
I think the referer is already checked, is it not in the core, then by Protector.
A stronger protection would be a token in eg forms. But because the server must remember these tokens eg in the session, this can lead to dos attacks. If it is not saved in the server, then the token can be guessed and then it is worthless. Other problems that arise with the tokens is when multiple tabs (or windows) are open with the same form or when the user uses 'Back' to restart the same form again and to post it with some modifications again as a second record.
This kind of attack is rather rare, because several conditions has to be fulfilled at once. It is also very difficult to have all holes covered. (Sometimes I think we need some additional security mode in the browser for this.)
