Prestashop: Prestashop 1.7.5.2 Several Security problem with folders permissions 777 & 666

Created on 4 Jul 2019  Â·  13Comments  Â·  Source: PrestaShop/PrestaShop

After upgrading prestashop 1.6 To 1.7.5.2
a big problem appears and touch the security of prestashop with 1.7.5.2 and file permission

Adding a module zip by admin, file permission is 777 & 666

Updating a module in listing file receive permission is 777 & 666

Upload a theme as zip all theme for 1.7 flies and folder receive permission is 777 & 666
update or clear cache folder file inside Var have permission is 777 & 666
if we correct the permissions after if we clear cache all folder and files situated on var will retrieve the permission is 777 & 666

If we modify the translations the permission is 777 & 666 if update translation the permission is 777 & 666
Mail folder the permission is 777 & 666
Admin if we go tho a part of menu : problem token appears ( and file have permission 777 & 666 automatically

Htaccess, sitemap, robot, new pictures added from cms page, ... all receive file have permission 777 & 666 automatically

We correct all permissions all the times but it come back after clear cache for example

This is not possible this very big problem appears and create instability for security from prestashop did you understand what it means Prestashop ?

I have seen many search from people have this problem and no answer no suggestion from prestashop

Paypal Official is also affected if we installed and update, inf fact all module from prestashop receive systematically the the permission is 777 & 666

Languages ... everything is touch,

Then today we must face to hacking tentative, and it seams that many shop from prestashop are affected by this problem

I have check with my webhoster Planethoster, and all configuration require for prestashop 1.7.5.2 db, pdo ... all in indicated on the documentation official from prestashop is ok ... this problem appears from all prestashop and we must each day see if we not have a hacking because prestashop is not secured and the most important things is we don't have this problem and never have this problem with prestashop 1.6

We have thinking that maybe is due softaculous, but if we install a new version of prestahop on new server, it made exactly the same problem and file permission receive all

The problem appears for different website using prestashop and no answer not correction finding

For us is 3 shop who's have exactly the same problem and two of them work with classic theme not modified and all module from prestashop

PHP version: 7.2.19
Check your configuration all is ok
Memory limit: 256M
Max execution time: 300
MySQL version: 10.2.25-MariaDB
Upload Max File size: 128M
PrestaShop version: 1.7.5.2
HTTPS with EV for me

Have file permission module or security lite not stable resolve problem for permissions

we need to each modification start again the file permission because all file var or act receive the permission folder 777 and 666 for file in place of 755 & 664

If we click on generate robot ( robot receive 666)
if we click Friendly URL htaccess receive 666

if we clic update module : 666 777
If we go to translation, update the language folder 777 666
if we update translation for the theme 777 666
if we clear cache : VAR + classic / assets/ cache : JS + CSS compiled is 666
etc .. etc ...

So prestashop ?????? what's the problem exactly ??? and when will you resolve this important problem !!! ???

1.7.5.2 Autoupgrade Duplicate

Most helpful comment

@didjou I will answer in English because this is an opensource and international project and we do not want to exclude the people who cannot speak French, even though PrestaShop was created by a French company. This is an open world 🌏maybe we'll have english speakers wishing to participate too

The PR does fix the issue you mention. So the issue is solved, and this will be delivered in incoming PS 1.7.6 version. I already explained the security strategy before and the new one, and I agree with you that this the previous strategy was not a good security practice, that is exactly why the PR was made and merged.

This security strategy about files and folders was decided a long time ago by people who do not work on PrestaShop anymore, and they had their reasons: whenever there is a security topic you have to choose whether 1) you make it open by default or 2) secured by default.

If you choose 1), this is the user's responsibility to ensure security. Please remember that PrestaShop is a software you install on a server. The same happens with a web server (apache), a database service (mysql) ... PrestaShop will do its best to protect you but in the end, the php code is on your server and yours to use and secure. For example some people say that apache should drop http and only enable https because http is now considered insecure by most people. Apache refuses to: again this is because they choose to let the user free to choose how he wants to configure the server and how he handles the security. These are tools, sometimes the tool should not dictate how you use it, and sometimes the tool should protect you even against your own will.

If you choose 2), you put in the necessary security protections but make it harder for newcomers to use, also some people want to have a very specific security configuration and this can make it harder for them to enable their dedicated configuration. You restrict their ability and make the project harder to use and harder to manage.

⏩ It's a never-ending debate between "freedom of configuration" and "the most secure possible".

You will find many examples of this debate outside of this project:

  • some websites require you to have a password with a upper char in it, a number in it, at least 10 letters / some websites let you choose whatever password you want
  • some hosting provides lock in the database service so it can only be used locally / some hosting providers let it full open
  • in USA (if I'm not wrong as it might have changed since then), there is no PIN code on credit cards / in France we require the PIN code

We could even add this example 😄: some countries decide to ban alcohol as it can have dangerous consequences on people's health, and other countries decide to let people free to choose how they consume it.

As you can see, this debate is far from being over. We have chosen the secure way now, but previous PS versions did not choose this way. Time changes, practices change.

Also the previous security strategy for files and folders was not a direct vulnerability issue. This was a bad practice that would help a hacker to gain access to a wider part of the server/app if he was able to find a point of injection, using a RCE or a LFI, but this was not a direct vulnerability.

All 13 comments

You can run my module to fix permissions: https://github.com/MathiasReker/filepermissions

Hi @didjou this issue has been fixed by https://github.com/PrestaShop/PrestaShop/pull/12124 .

You can read the pull request to understand why the system was like this before and why it has changed, but I can summarize it like this:
"Before, PrestaShop was open by default and required shop admins to protect it because we know that some of our users do not have either knowledge or capabilities to manage the file permissions. So it was the user's responsibility to secure correctly its files and folders. We have changed this behavior to 'open by default' to 'secured by default'".

This was not an easy choice as we know some unexperienced prestashop users will have a hard time understanding what is needed to do, but we have chose security over accessibility.

You can run my module to fix permissions: https://github.com/MathiasReker/filepermissions
Thank mathias i have it but please understand this is not secure and we need to do if we made clear cache adding a new picture, etc .. etc ... so it help but it's not a stable solution

and this is not possible to have this problem and must have a module to resolve a temporary the problem because it appears each time modification as a little part

So thank you for your work and the module who's help but i will not this big problem security is not considered and not resolves

@matks matks Heuu are you killing ? secure solution that all folder will in 666 and 777

Prestashop is not on good way, and very afraid to see that all shop that prestashop was so happy to said hey they are the best they use prestashop are going to other solution to be sure to have a futur with their shop

this is not possible to do this and also not explain clearly the procedure : in my pap version gd and all is for symphony is installed, so you take 2 minutes to be sure to explain clearly and sure resolve the problem of this big and important problem sécurity

@matks matks Heuu are you killing ? secure solution that all folder will in 666 and 777

Read the PR please 😉it puts everything to 0755 or 0644

@matks and when we update prestashop for 1.7.6 we need to do again, so each time we update we nee to touch one the file :
classes/PrestaShopAutoload.php
admin-dev/ajax-tab.php
controllers/admin/AdminCartsController.php
controllers/front/ProductController.php

And you prefer for security to permits to a new vendor who's starting without developper to insecure his shop and permissions to all hacker and all kind of problem to acces freely rewrite files htacess etc ... and sure touch the integrity of online payment with papaya official for example so you prefer for security to permisss insecurity and so destroy a shop and the person who have the shop

[ moderated ]

And you prefer for security to permits to a new vendor who's starting without developper to insecure his shop and permissions to all hacker and all kind of problem to acces freely rewrite files htacess etc ... and sure touch the integrity of online payment with papaya official for example so you prefer for security to permisss insecurity and so destroy a shop and the person who have the shop

@matks

En français au cas ou parce bon c'est bien Gentil mais prestashop est aussi français, et nombreux marchands sont français, comme beaucoup de désespérés à ce sujet de permission et qui ne trouvent pas la solution et ne savent pas quoi faire voir le truc : #12124 > C'est tellement simple quand on est pas développer et simple marchand qui veux juste vendre ses produits !

Il faut donc modifier :
classes/PrestaShopAutoload.php
controllers/admin/AdminCartsController.php
controllers/front/ProductController.php
src/Core/Foundation/Filesystem/FileSystem.php Outdated
admin-dev/ajax-tab.php

Et donc quand on fera la prochaine update par exemple vers 1.7.6 on devra donc recommencer le tout car ce ne sera pas modifier c'est bien cela !?

Donc vous préférez par sécurité, permettre aux hackers, a toutes les personnes mal intentionnées de pouvoir modifier une boutique prestashop lancée par un marchands débutant sans savoir ce problÚme de sécurité et de permissions car combien ne sont pas au courant ? et donc mettre à mal ainsi le vendeur et sa boutique car cela touche tous les modules et fichier y compris les moyens de paiement .. parce par sécurité prestashop à préférer permettre ce type de procédure non sécurisé !

Merci beaucoup Prestashop ! et merci pour laisser cette insécurité totale s'installée et permettre le hacking d'une boutique comme nous venons de le subir parce que prestashop l'a voulu par sécurité !

@matks Désolé mais ou je modifie et quoi exactement impossible de m'y retrouver dans tout ce charabia est ce possible de faire une réponse SIMPLE et CLAIR sur ce qu'on doit MODIFIER pour éviter cette situation

Merci Beaucoup !

@didjou, You need to follow those files: https://github.com/PrestaShop/PrestaShop/pull/12124/files which fixes the issue.
Thanks!

@didjou I will answer in English because this is an opensource and international project and we do not want to exclude the people who cannot speak French, even though PrestaShop was created by a French company. This is an open world 🌏maybe we'll have english speakers wishing to participate too

The PR does fix the issue you mention. So the issue is solved, and this will be delivered in incoming PS 1.7.6 version. I already explained the security strategy before and the new one, and I agree with you that this the previous strategy was not a good security practice, that is exactly why the PR was made and merged.

This security strategy about files and folders was decided a long time ago by people who do not work on PrestaShop anymore, and they had their reasons: whenever there is a security topic you have to choose whether 1) you make it open by default or 2) secured by default.

If you choose 1), this is the user's responsibility to ensure security. Please remember that PrestaShop is a software you install on a server. The same happens with a web server (apache), a database service (mysql) ... PrestaShop will do its best to protect you but in the end, the php code is on your server and yours to use and secure. For example some people say that apache should drop http and only enable https because http is now considered insecure by most people. Apache refuses to: again this is because they choose to let the user free to choose how he wants to configure the server and how he handles the security. These are tools, sometimes the tool should not dictate how you use it, and sometimes the tool should protect you even against your own will.

If you choose 2), you put in the necessary security protections but make it harder for newcomers to use, also some people want to have a very specific security configuration and this can make it harder for them to enable their dedicated configuration. You restrict their ability and make the project harder to use and harder to manage.

⏩ It's a never-ending debate between "freedom of configuration" and "the most secure possible".

You will find many examples of this debate outside of this project:

  • some websites require you to have a password with a upper char in it, a number in it, at least 10 letters / some websites let you choose whatever password you want
  • some hosting provides lock in the database service so it can only be used locally / some hosting providers let it full open
  • in USA (if I'm not wrong as it might have changed since then), there is no PIN code on credit cards / in France we require the PIN code

We could even add this example 😄: some countries decide to ban alcohol as it can have dangerous consequences on people's health, and other countries decide to let people free to choose how they consume it.

As you can see, this debate is far from being over. We have chosen the secure way now, but previous PS versions did not choose this way. Time changes, practices change.

Also the previous security strategy for files and folders was not a direct vulnerability issue. This was a bad practice that would help a hacker to gain access to a wider part of the server/app if he was able to find a point of injection, using a RCE or a LFI, but this was not a direct vulnerability.

Thanks khouloudbelguith :) & Maks, :)
Yes i know but also sometimes it's difficult to find a solution in french i take time to read in english but some of marchands are not perfect bilingual also when it's about Technical problem in english it's a nightmare to understand and try to resolve the problem, so sometimes french help to more understand and sure not made mistake for understanding word . But be sure i try to do my best to come here to read all in english but sometimes it's like was shaking beer you open without knowing ... you receive all in face but not sure to understand all ;)

In fact sometimes we are sad, afraid, because we not all understand, ( for myself i splash in prestashop since 2009 and today i not all understand some of subtibility ) and i think that problem if we translate in french will help some merchant too ( it's for helping others person who have difficult to understand all nothing else )

I'm very happy to progress and go to future with prestashop sometimes we are sad about it but in fact it's because we love it :)

so i'm impatient for 1.7.6 with some great little new change, in my way i always hope in prestashop and hope better all the time sometimes like perfect solution .... but this some unperfection made also happiness for us

At this moment i will try to really understand where and what i must change in the file and be patient to next version

Have a great day
and thank you very much to be there and help us !
and sorry if sometime i was sad writing

:)

Duplicate of #12108

Was this page helpful?
0 / 5 - 0 ratings