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