Vulnerabilities found while the penetration test

My OJS 3.0.2 was hacked on 13th June 2017. I have to reformat and reinstall all new. Now our ICT team had run a penetration test before opening the system to make sure it is safe. From the test results, I was advised to resolve the high and medium risk issues. Therefore, I need some advice and guidance on how to solve these issues.

  1. High risk

Using the GET HTTP method, it is found that :

  • The following resources may be vulnerable to blind SQL injection :
  • The ‘source’ parameter of the /index.php/PMJET/login/signIn CGI :
    /index.php/PMJET/login/signIn?username=&csrfToken=5f53622ec36b57875e6607
    d96a02b3d9&password=&remember=1&source=zz&csrfToken=5f53622ec36b57875e66
    07d96a02b3d9&password=&remember=1&source=yy
    -------- output --------
 </div>

 <input type="hidden" name="source" value="" />
 <fieldset class="fields">

-------- vs --------

 </div>

 <input type="hidden" name="source" value="yy" />
 <fieldset class="fields">

/index.php/PMJET/login/signIn?username=&csrfToken=5f53622ec36b57875e6607
d96a02b3d9&password=&remember=1&source=zz&csrfToken=5f53622ec36b57875e66
07d96a02b3d9&password=&remember=1&source=yy {2}
-------- output --------

 </div>

 <input type="hidden" name="source" value="" />
 <fieldset class="fields">

-------- vs --------

 </div>

 <input type="hidden" name="source" value="yy" />
 <fieldset class="fields">

  • The ‘username’ parameter of the /index.php/PMJET/user/registerUser CGI :
    /index.php/PMJET/user/registerUser?readerGroup[442]=1&reviewerGroup[441]
    =1&email=&csrfToken=5f53622ec36b57875e6607d96a02b3d9&country=&authorGrou
    p[439]=1&affiliation[en_US]=&firstName=&lastName=&middleName=&password=&
    password2=&username=zz1&reviewerGroup[441]=1&email=&csrfToken=5f53622ec3
    6b57875e6607d96a02b3d9&country=&authorGroup[439]=1&affiliation[en_US]=&f
    irstName=&lastName=&middleName=&password=&password2=&username=yy
    -------- output --------
 <span class="pkp_form_error">Errors occurred processing this for [...]
 <ul class="pkp_form_error_list">
 <li><a href="#username">A username is required.</a></li>
 <li><a href="#password">A password is required.</a></li>
 <li><a href="#firstName">A first name is required.</a></li>

-------- vs --------

 <span class="pkp_form_error">Errors occurred processing this for [...]
 <ul class="pkp_form_error_list">
 [...] 

2… Medium risk

The following pages do not use a clickjacking mitigation response header and contain a clickable
event :

3… Medium risk

Using the GET HTTP method, It is found that :

  • The following resources may be vulnerable to unseen parameters :
  • The ‘source’ parameter of the /index.php/PMJET/user/register CGI :
    /index.php/PMJET/user/register?source=&source=1
    -------- output --------
 <input type="hidden" name="csrfToken" value="46476637656dec72748 [...]


 <fieldset class="identity">

-------- vs --------

 <input type="hidden" name="csrfToken" value="46476637656dec72748 [...]
 <input type="hidden" name="source" value="1" />

  • The ‘source’ parameter of the /index.php/PMJET/user/registerUser CGI :
    /index.php/PMJET/user/registerUser?username=&reviewerGroup[441]=1&email=
    &csrfToken=5f53622ec36b57875e6607d96a02b3d9&country=&authorGroup[439]=1&
    affiliation[en_US]=&firstName=&lastName=&middleName=&password=&password2
    =&readerGroup[442]=1&source=1
    -------- output --------
15
 <input type="hidden" name="csrfToken" value="01aa8d343f8c76a82b4 [...]

 <div id="formErrors">
 <span class="pkp_form_error">Errors occurred processing this for [...]

-------- vs --------

 <input type="hidden" name="csrfToken" value="01aa8d343f8c76a82b4 [...]
 <input type="hidden" name="source" value="1" />

 <div id="formErrors">

  • The ‘source’ parameter of the /index.php/bej/user/registerUser CGI :
    /index.php/bej/user/registerUser?username=&reviewerGroup[390]=1&email=&c
    srfToken=5f53622ec36b57875e6607d96a02b3d9&country=&authorGroup[388]=1&af
    filiation[en_US]=&firstName=&lastName=&middleName=&password=&password2=&
    readerGroup[391]=1&source=1
    -------- output --------
 <input type="hidden" name="csrfToken" value="80d3f953b79f782d98b [...]

 <div id="formErrors">
 <span class="pkp_form_error">Errors occurred processing this for [...]

-------- vs --------

 <input type="hidden" name="csrfToken" value="80d3f953b79f782d98b [...]
 <input type="hidden" name="source" value="1" />

 <div id="formErrors">

  • The ‘source’ parameter of the /index.php/bej/login CGI […]

Will appreciate it if you could kindly provide some help to resolve these issues. Thank you

Hi, @tdmy,

I’ve formatted your post to allow the HTML snippets you’ve provided to be rendered. You can use syntax of three backticks to format code on the forum:

here

The most likely scenario for the compromise you describe is a misconfiguration to make your files_dir directly accessible from the web. Was this the case for you? Have you corrected that configuration error, if present?

Can you provide more information on the concern with the “source” parameter in the login process?

This parameter represents an ultimate redirect location after a successful login. I don’t see any evidence of a SQL injection vulnerability, nor of a HTML injection vulnerability here.

The “source” redirect location is not checked to be a location internal to OJS, so this could provide a malicious user the opportunity to craft a URL where someone logs into OJS but is then redirected to another site after login. No user credentials would be exposed in this, and this could not be used as a method of attacking OJS directly; but it could be used as a method of confusing the end user.

The mitigation of clickjacking via a response header is best addressed by a webserver configuration. See:
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

You’ll want to configure your webserver with an appropriate X-Frame-Options response header. For example, in Apache, you could:

Header set X-Frame-Options SameOrigin

Dear @ctgraham,

That helps a lot and i will try to explain to our security team regarding the “source”. Will add the Header as suggested in the apache.

As for the files_dir, it does not reside in the application server or www, it is outside and in another storage server. I have also confirmed that the php engine is off in the server so that any uploaded script as file, cannot be executed.
Is there any other configuration needed for the files_dir that I have missed? Where can i refer?

Appreciate your help. Thank you.

Locating the files_dir such that is is not directly accessible via the web and disabling server-based scripting for that directory is a good configuration.

Note that relocating the directory to another storage server is not, in and of itself, sufficient. It is possible to have a directory on a remote server, and yet still make that location directly accessible from the webserver. A remote storage location which is not directly web accessible is a good configuration.

Your security team is welcome to hop on the forum and discuss any history, concerns, and remediation here. We’d be happy to work with your experts to confirm that all issues are addressed.

Dear @ctgraham,

Yes I have made sure the files_dir is not directly accessible via web and the security team is running another penetration test now. Thank you.