2

I recently had a breach on my site (laravel). I got aware of it after I tried to pull the code from github and found out that some files were modified.

The files modified were mostly storage - logs/cache and index.php had error_reporting(E_ALL) in it.

And I am not sure what happened and like to know if there's a way an attacker can access the server through the site and also what precautions I can take to mitigate these kinds of scenarios.

I researched a little bit and found out about these methods. Can anyone explain which method could possibly give access to an attacker to actually modify code files:

Cross Site Request Forgery - I dont understand much about how this works.

Cross Site Scripting - There are very less users using the site at this point and authorization & authentication is in place.

Local File Inclusion - Laravel uses namespaces and no such inclusions is made directly is it still a concern then?

Remote File Inclusion - Laravel uses namespaces and no such inclusions is made directly is it still a concern then?

Session Hijacking - PHP Sessions were not in use as it was a api based service and used jwt token

Session Identifier Acquirement - PHP Sessions were not in use as it was a api based service and used jwt token.

SQL Injection - All the db queries uses laravel eloquent so there might be no sql injection.

Improve this question
10
  • 2
    If a site allows uploading files and doesn't appropriately whitelist paths that can execute CGI scripts, then someone may upload a polyglot file which is seen as an image file to the filter that allows or denies uploads, but as an executable script to the server when accessed later. Is that what you're asking about?
    – forest
    Commented Mar 7, 2021 at 8:33
  • 1
    This question cannot be answered without doing an in-depth analysis of your server setup and of your code. First, such in-depth analysis is too broad and therefore off-topic. Then there are not even enough information for this, i.e. basically the only information are that you use laravel. I recommend that you get a local expert to look at your setup or maybe let others manage your system in the first place.
    – Steffen Ullrich
    Commented Mar 7, 2021 at 9:05
  • 1
    Congratulations! You have now learned the importance of application security, and it sounds like you have done it before you were out in charge of a multi-million dollar system or large amounts of user data! Do yourself a favor and learn the most important lesson: if you throw code and infrastructure up without considering basic security needs, you will be hacked. Time to start training yourself on application security!
    – Conor Mancone
    Commented Mar 7, 2021 at 13:12
  • 1
    @php.prg: so far you've listed several techniques which might lead to a problem and several which don't. You completely ignored though that the site could have hacked by other means apart from issues in your application, like insecure or stolen access credentials for SSH or the admin interface, bugs in the admin interface, other applications on the same server, insecure hosting ... .
    – Steffen Ullrich
    Commented Mar 7, 2021 at 17:30
  • 1
    @php.prg: Like I said: the question cannot be answered without in in-depth analysis of your code - which is off-topic. There can be for example logic errors which allow unauthorized access. There were also various security issues in the laravel framework in the past.
    – Steffen Ullrich
    Commented Mar 7, 2021 at 20:39

2 Answers 2

Reset to default
3

Via uploading a file and executing it. Review uploads, php enabled functions and use 'noexec' (in UNIX/Linux) mount option on filesystem. If your app must execute local binaries, create a regular job to review which binaries are available to the app. Think about using chroot or namespaces for PHP app.

Improve this answer
1

Yes there is an option the attacker accessed the files and modified them. Check log files on the server which files were modified and how, compare them because probably he left an backdoor so he can come back later or modified some files in a way so he can do something malicious, also check for unknown files a.k.a "Shell" which attackers use to gain control over the system. You can prevent this by securing that all upload forms (if you have) do not allow .php .asp etc file extensions so none can upload an shell or something similar. If the attacker enabled the error reporting probably he was looking for more vulnerabilities in the code.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .