Hi!
But then such a file should not be included in the release, or at least renamed to "test.php.txt" so that it can only be executed after being renamed?
why? the lang scripts are not renamed too from .sh to .sh.txt ... and don't make it too hard for theme developers - probably they are not techies
.sh scripts cannot be executed through HTTP. .php Scripts can.
Why did Michal then fix this a day ago?
i don't know, i mean it is not wrong to escape this value, but it is not really necessary, you can not reach the host you want if you add XSS code to the host in the http header ... IMHO!
That depends on the Apache setup. If you use HTTP 1.0 you can specify the Host: Header with any content you like. Plus you might be able to pass $HTTP_HOST as a register_global variable.
Regards, Garvin
Garvin Hicking wrote:
Hi!
But then such a file should not be included in the release, or at least renamed to "test.php.txt" so that it can only be executed after being renamed?
why? the lang scripts are not renamed too from .sh to .sh.txt ... and don't make it too hard for theme developers - probably they are not techies
.sh scripts cannot be executed through HTTP. .php Scripts can.
depends on server configuration ... ok, but why should we prevent this?
Why did Michal then fix this a day ago?
i don't know, i mean it is not wrong to escape this value, but it is not really necessary, you can not reach the host you want if you add XSS code to the host in the http header ... IMHO!
That depends on the Apache setup. If you use HTTP 1.0 you can specify the Host: Header with any content you like. Plus you might be able to pass $HTTP_HOST as a register_global variable.
mhm, PMA does not use register_globals and even deletes already registered globals
but anyway, i will change this
Hi Sebastian!
.sh scripts cannot be executed through HTTP. .php Scripts can.
depends on server configuration ... ok, but why should we prevent this?
I've never seen a server where .sh scripts can be executed with a usual webapplication folder. If bash files are executed, they usually have to live within a cgi-bin folder, and even then, .sh is seldom included in the CGI-folder. Plus, such a file would have the "execute" flag set, which PHP scripts don't require.
We should prevent accessing PHP scripts that are not required for phpMyAdmin operation, to not create a attack/intrusion vector for possible hackers. If that file is only required for developers, only make it available for developers, or make developers to change the filename to be able to execute it. Don't bother the usual user with such a file, for whom such a file can only do evil and nothing good.
Header with any content you like. Plus you might be able to pass $HTTP_HOST as a register_global variable.
mhm, PMA does not use register_globals and even deletes already registered globals
That's what the last couple of security bugfixes were about. Until the code has ben FULLY reworked, we cannot guarantee there are still register_global issues left. :-)
but anyway, i will change this
Thanks!
Best regards, Garvin
Garvin Hicking wrote:
Hi Sebastian!
.sh scripts cannot be executed through HTTP. .php Scripts can.
depends on server configuration ... ok, but why should we prevent this?
I've never seen a server where .sh scripts can be executed with a usual webapplication folder. If bash files are executed, they usually have to live within a cgi-bin folder, and even then, .sh is seldom included in the CGI-folder. Plus, such a file would have the "execute" flag set, which PHP scripts don't require.
hey, this was a joke and never seen means not never happens!
We should prevent accessing PHP scripts that are not required for phpMyAdmin operation, to not create a attack/intrusion vector for possible hackers. If that file is only required for developers, only make it available for developers, or make developers to change the filename to be able to execute it. Don't bother the usual user with such a file, for whom such a file can only do evil and nothing good.
change it ... if you like ... i dont see it like you do ...
Header with any content you like. Plus you might be able to pass $HTTP_HOST as a register_global variable.
mhm, PMA does not use register_globals and even deletes already registered globals
That's what the last couple of security bugfixes were about. Until the code has ben FULLY reworked, we cannot guarantee there are still register_global issues left. :-)
this security fixes were BEFORE PMA always reverts register_globals
so its not more a 'register globals' problem than 'what does PMA automatically import' problem.
Hi Sebastian!
I've never seen a server where .sh scripts can be executed with a usual webapplication folder. If bash files are executed, they usually have to live within a cgi-bin folder, and even then, .sh is seldom included in the CGI-folder. Plus, such a file would have the "execute" flag set, which PHP scripts don't require.
hey, this was a joke and never seen means not never happens!
I'm sorry then, I didn't get the joke. :)
We should prevent accessing PHP scripts that are not required for phpMyAdmin operation, to not create a attack/intrusion vector for possible hackers. If that file is only required for developers, only make it available for developers, or make developers to change the filename to be able to execute it. Don't bother the usual user with such a file, for whom such a file can only do evil and nothing good.
change it ... if you like ... i dont see it like you do ...
I would like to get feedback of Marc or Michal, how do you feel about that?
That's what the last couple of security bugfixes were about. Until the code has ben FULLY reworked, we cannot guarantee there are still register_global issues left. :-)
this security fixes were BEFORE PMA always reverts register_globals
I haven't seen the new code yet, but if you say we have a working code that makes injecting global variables IMPOSSIBLE, then please disregard my concern.
so its not more a 'register globals' problem than 'what does PMA automatically import' problem.
Well, to me both questions lead to the same security issue about injecting variables that PMA did not want.
Best regards, Garvin
Garvin Hicking a écrit :
Hi Sebastian!
I've never seen a server where .sh scripts can be executed with a usual webapplication folder. If bash files are executed, they usually have to live within a cgi-bin folder, and even then, .sh is seldom included in the CGI-folder. Plus, such a file would have the "execute" flag set, which PHP scripts don't require.
hey, this was a joke and never seen means not never happens!
I'm sorry then, I didn't get the joke. :)
We should prevent accessing PHP scripts that are not required for phpMyAdmin operation, to not create a attack/intrusion vector for possible hackers. If that file is only required for developers, only make it available for developers, or make developers to change the filename to be able to execute it. Don't bother the usual user with such a file, for whom such a file can only do evil and nothing good.
change it ... if you like ... i dont see it like you do ...
I would like to get feedback of Marc or Michal, how do you feel about that?
I'm sorry, has this issue been solved with yesterday's commits?
Marc
That's what the last couple of security bugfixes were about. Until the code has ben FULLY reworked, we cannot guarantee there are still register_global issues left. :-)
this security fixes were BEFORE PMA always reverts register_globals
I haven't seen the new code yet, but if you say we have a working code that makes injecting global variables IMPOSSIBLE, then please disregard my concern.
so its not more a 'register globals' problem than 'what does PMA automatically import' problem.
Well, to me both questions lead to the same security issue about injecting variables that PMA did not want.
Best regards, Garvin
-
Garvin Hicking -
Marc Delisle -
Sebastian Mendel