EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #08023


< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] CSRF


Hi Maher,

To check whether the CSRF token is appearing you will need to look into the HTML source for something like:

<input id="csrf_token" name="csrf_token" type="hidden" value="<TIMESTAMP>:<HASH>" />

Where
<TIMESTAMP> is something like 1573375123 and <HASH> is something like 0123456789abcdef0123456789abcdef.  You will need to have at least reloaded Apache (e.g. apachectl graceful) for the addition of EPRINTS_PATH/archives/ARCHIVE_NAME/cfg/cfg.d/csrf_protection.pl to be applied to you running configuration.  The HTML shown above will only appear in forms if you are logged in as a user.  So will not appear in the actual login form (/cgi/users/login) or the search forms (/cgi/search/simple or/cgi/search/advanced) unless you are logged in.  CSRF protection only applies when an authenticated user is trying to make a request, as they would likely have permissions that an unauthenicated user may not.

One thing that should be noted is that staticly generated abstract pages will not contain csrf_token's for their export forms.  This is because these exports do not require user authentication and as the page and subsequently the form are generated without the concept of a user being logged in the forms will not get a csrf_token.  I guess this would cause an uninformed vulnerability scanner to report an error.  Either you should add an exception to your scanner or if it is still a concern (although I believe it causes no security risk) remove the tools box from your abstract page configuration.  I would usually add the following line to ARCHIVENAME/cfg/cfg.d/plugins.pl:

$c->{plugins}{"Screen::EPrint::Box::Tools"}{params}{disable} = 1;

Before reloading Apache, you will need to run:

EPRINTS_PATH/bin/epadmin refresh_abstracts ARCHIVE_NAME

Hopefully this is helpful.  There may be other places where read-only forms like abstract page export exists that could record an error in your vulnerability scanner.  If you could report specific pages and the specific action URLs of the forms that is reporting the vulnerability, I can take a look.  If it is something that effects a whole class of pages like the abstract page situation I described, a single example should be sufficient for me to investigate.

Regards

David Newman


On 10/11/2019 05:24, Maher Abdellatif Ahmad Qahwash wrote:

Hi Newman,

It's a new installation and the file exist under this path (EPRINTS_PATH /archives/ ARCHIVE_NAME /cfg/cfg.d) but our security team is doing a vulnerability scan using Acunetix and it's giving CSRF Token missing error on all pages.

Is there a way we can verify that CSRF token are being applied?

 

 

From: Newman D.R. [mailto:drn@ecs.soton.ac.uk]
Sent: Thursday, November 07, 2019 3:13 PM
To: eprints-tech@ecs.soton.ac.uk; Maher Abdellatif Ahmad Qahwash
Subject: Re: [EP-tech] CSRF

 

تحذير: هذه الرسالة مرسلة من خارج الجامعة. لا تفتح أي مرفق أو رابط ما لم تكن متأكداً من أنه آمن
Warning: This mail has been sent from outside KFUPM. Do not open links or attachments unless you are sure they are safe.
____________________________________________________________

Hi Maher,

This depends if you have just created a new repository/archive or if you have upgraded to 3.4.1 for an existing archive.  For the latter you will need to manually copy EPRINTS_PATH/lib/defaultcfg_zero/cfg.d/csrf_protection.pl to you archive (i.e.  EPRINTS_PATH/archives/ARCHIVE_NAME/cfg.d/csrf_protection.pl).  Otherwise csrf_protection.pl should have automatically added to you archive on creation.  Either way it is best you change the csrf_token_salt config variable to something else.  Generating a suitable token salt can be done using OpenSSL:

openssl rand -base64 8

8 characters should be more than sufficient, as the current time is also used in generating each token.  Using the default token salt gives you improved security but is not ideal as a determined hacker could work out valid tokens they could use.

Regards

David Newman

On 07/11/2019 11:54, Maher Abdellatif Ahmad Qahwash via Eprints-tech wrote:

Hi

 

We are running eprints 3.4.1 and would like know if CSRF is enabled by default or we need to enable it in the configuration?

 

Thanks

Maher



*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/