|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
|
|
Securing typo3confI've the feeling /typo3conf should be totally forbidden for any web access, because it contains too much files (i.e. constants, setup) which should not be accessed directly from web. So I deny access to /typo3conf in my website configuration, and all works, except for some routines which must be explicited enabled. Up to now (for what I'm using now), paths I must enable are: * /typo3conf/ext/sr_freecap/pi1/captcha.php * /typo3conf/ext/sr_freecap/pi2/newFreeCap.js * /typo3conf/ext/dam_frontend/pushfile.php But I have some questions: * how is generally considered the security of /typo3conf path? * should be introduced a zone where plugins should place routines/files which should be generally accessible? Should exist another place (i.e. like /typo3public/ or /typo3conf/public/) where extensions should automatically place any file which is accessed directly from web, denying instead any direct access to /typo3conf? Thanks, Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@... ------------------------------------------------------------ _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination |
|
|
Re: Securing typo3confHi Torino
Which setup and constants files are you worried about being publicly accessed? As I see it, only extensions come with their default setup and constans TS code, that can be publicly accessed. Since these files are readable in the TER, there should be no security problem there. The only way I could imagine this being a problem, would be if you created your own extension, and started putting passwords in the default TS configuration of the extension, and that would be very bad! - Søren Andersen -----Oprindelig meddelelse----- Fra: typo3-team-extension-coordination-bounces@... [mailto:typo3-team-extension-coordination-bounces@...] På vegne af Tonix (Antonio Nati) Sendt: 26. august 2008 11:31 Til: typo3-team-extension-coordination@... Emne: [TYPO3-ect] Securing typo3conf I've the feeling /typo3conf should be totally forbidden for any web access, because it contains too much files (i.e. constants, setup) which should not be accessed directly from web. So I deny access to /typo3conf in my website configuration, and all works, except for some routines which must be explicited enabled. Up to now (for what I'm using now), paths I must enable are: * /typo3conf/ext/sr_freecap/pi1/captcha.php * /typo3conf/ext/sr_freecap/pi2/newFreeCap.js * /typo3conf/ext/dam_frontend/pushfile.php But I have some questions: * how is generally considered the security of /typo3conf path? * should be introduced a zone where plugins should place routines/files which should be generally accessible? Should exist another place (i.e. like /typo3public/ or /typo3conf/public/) where extensions should automatically place any file which is accessed directly from web, denying instead any direct access to /typo3conf? Thanks, Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@... ------------------------------------------------------------ _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-co ordination _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination |
|
|
Re: Securing typo3confHi Søren,
generally speaking, I feel none should be able to even guess what I have loaded inside my typo3, and if I'm using or not standard constants or setup files. A well planned query could understand all extensions I have, and try to use a security hole of the extension (eventually). Tonino Søren Andersen ha scritto: > Hi Torino > > Which setup and constants files are you worried about being publicly > accessed? > As I see it, only extensions come with their default setup and constans TS > code, that can be publicly accessed. Since these files are readable in the > TER, there should be no security problem there. > The only way I could imagine this being a problem, would be if you created > your own extension, and started putting passwords in the default TS > configuration of the extension, and that would be very bad! > > - Søren Andersen > > -----Oprindelig meddelelse----- > Fra: typo3-team-extension-coordination-bounces@... > [mailto:typo3-team-extension-coordination-bounces@...] På > vegne af Tonix (Antonio Nati) > Sendt: 26. august 2008 11:31 > Til: typo3-team-extension-coordination@... > Emne: [TYPO3-ect] Securing typo3conf > > > I've the feeling /typo3conf should be totally forbidden for any web > access, because it contains too much files (i.e. constants, setup) > which should not be accessed directly from web. > > So I deny access to /typo3conf in my website configuration, and all > works, except for some routines which must be explicited enabled. > Up to now (for what I'm using now), paths I must enable are: > > * /typo3conf/ext/sr_freecap/pi1/captcha.php > * /typo3conf/ext/sr_freecap/pi2/newFreeCap.js > * /typo3conf/ext/dam_frontend/pushfile.php > > But I have some questions: > > * how is generally considered the security of /typo3conf path? > * should be introduced a zone where plugins should place > routines/files which should be generally accessible? Should exist > another place (i.e. like /typo3public/ or /typo3conf/public/) > where extensions should automatically place any file which is > accessed directly from web, denying instead any direct access to > /typo3conf? > > Thanks, > > Tonino > > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@... ------------------------------------------------------------ _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination |
|
|
Re: Securing typo3confHi Tonix,
> I've the feeling /typo3conf should be totally forbidden for any web > access, because it contains too much files (i.e. constants, setup) > which should not be accessed directly from web. > > So I deny access to /typo3conf in my website configuration, and all > works, except for some routines which must be explicited enabled. > Up to now (for what I'm using now), paths I must enable are: > > * /typo3conf/ext/sr_freecap/pi1/captcha.php > * /typo3conf/ext/sr_freecap/pi2/newFreeCap.js > * /typo3conf/ext/dam_frontend/pushfile.php frontend and/or backend. gruss, martin _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination |
|
|
Re: Securing typo3confMartin Holtz ha scritto:
> Hi Tonix, > > >> I've the feeling /typo3conf should be totally forbidden for any web >> access, because it contains too much files (i.e. constants, setup) >> which should not be accessed directly from web. >> >> So I deny access to /typo3conf in my website configuration, and all >> works, except for some routines which must be explicited enabled. >> Up to now (for what I'm using now), paths I must enable are: >> >> * /typo3conf/ext/sr_freecap/pi1/captcha.php >> * /typo3conf/ext/sr_freecap/pi2/newFreeCap.js >> * /typo3conf/ext/dam_frontend/pushfile.php >> > keep in mind, that some extensions have css/icons etc. which are used in > frontend and/or backend. > > > I see there are too much problems before I can use this kind of protections with actual typo3. But I feel this is something typo3 development group should consider in future development. If there is a security hole in one extension it is very easy to check if a site uses that extension. So, probably something must be changed in the future, or splitting extension in two different zones (private and public, where public contains CSS, gif, ecc), or registering extensions in a different way (it could be enough to register each extension in a random way - i.e. EXT:/23fa45eg_extension_name/..., where the random key is stored inside localconf.php), or both solutions together. Just my 1 cent consideration. Regards, Tonino > gruss, > martin > _______________________________________________ > TYPO3-team-extension-coordination mailing list > TYPO3-team-extension-coordination@... > http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination > > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@... ------------------------------------------------------------ _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination |
|
|
Re: Securing typo3confHi,
whenever there is a pulic part of the Extension it would be easy to check if the extension exists or not. Because everybody knows what would be in this public part an may test for. Random path would no help either because in you HTML Code the path to the public folder has to be included, to use CSS or Images and so on. But as others said before: I do not think that there is a security risk. Even if they know what Extensions im Using it would be difficult to determine the version. So far... Steffen _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination |
|
|
Re: Securing typo3confSteffen Ritter wrote: on 08.09.2008 16:51:
> Hi, > whenever there is a pulic part of the Extension it would be easy to > check if the extension exists or not. Because everybody knows what would > be in this public part an may test for. Random path would no help either > because in you HTML Code the path to the public folder has to be > included, to use CSS or Images and so on. > > But as others said before: I do not think that there is a security risk. > Even if they know what Extensions im Using it would be difficult to > determine the version. > So far... It is usually very easy, just grab http://domain/typo3conf/ext/tt_news/ChangeLog or some other text file that is not protected per se. In TYPO3 v5 there is a clear distinction between those parts that are the "code" and the public resources, which are handled by some resource manager. So if it is a confort, that problem is well known and will be handled much better in TYPO3 v5, but I guess there is no easy solution to that in TYPO3 v4. Cheers, Ernesto _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination |
|
|
Re: Securing typo3confErnesto Baschny [cron IT] ha scritto:
> Steffen Ritter wrote: on 08.09.2008 16:51: > >> Hi, >> whenever there is a pulic part of the Extension it would be easy to >> check if the extension exists or not. Because everybody knows what would >> be in this public part an may test for. Random path would no help either >> because in you HTML Code the path to the public folder has to be >> included, to use CSS or Images and so on. >> >> But as others said before: I do not think that there is a security risk. >> Even if they know what Extensions im Using it would be difficult to >> determine the version. >> So far... >> > > It is usually very easy, just grab > http://domain/typo3conf/ext/tt_news/ChangeLog or some other text file > that is not protected per se. > > In TYPO3 v5 there is a clear distinction between those parts that are > the "code" and the public resources, which are handled by some resource > manager. So if it is a confort, that problem is well known and will be > handled much better in TYPO3 v5, but I guess there is no easy solution > to that in TYPO3 v4. > > It is important to know this problem is known and will be solved in future. Thanks, Tonino > Cheers, > Ernesto > _______________________________________________ > TYPO3-team-extension-coordination mailing list > TYPO3-team-extension-coordination@... > http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination > > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@... ------------------------------------------------------------ _______________________________________________ TYPO3-team-extension-coordination mailing list TYPO3-team-extension-coordination@... http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination |
| Free embeddable forum powered by Nabble | Forum Help |