[PHP] Leuk printf + include trucje, maar is het correct?

[Wolf3D]

Heren (en dames),

Ik heb een stukje werkende PHP code, maar ik vraag me af of wat ik doe wel helemaal goed is en of het aan te raden is om het op deze manier te doen.

Ik wil een include plaatsen op een variabele plek in een stuk tekst. Momenteel heb ik dat op de volgende manier opgelost:

test.php:
=============

PHP:

<?php 
$string = "In deze string kan ik bepalen waar %s de include geplaatst wordt!";
printf($string, include_once('include.php'));
?>

include.php
=============

PHP:

<?php
return $_GET['test'];
?>

Als ik nu aanroep test.php?test=lalalalalala dan krijg ik terug:

In deze string kan ik bepalen waar lalalalalala de include geplaatst wordt!

Het werkt dus prima!
Nou vraag ik me af (voordat ik hiermee verder ga) of bovenstaande een goede oplossing is, of dat dit een verkeerde en misschien onveilige manier is.

Ik wil dit namelijk gebruiken in mijn CMS, waar gebruikers hun pagina's kunnen editen, maar in sommige gevallen is een extern bestand nodig (dynamische pagina's, formulieren, enz). Op deze manier wil ik dat in de pagina zelf aangegeven kan worden waar de dynamische content geplaatst moet worden.

Graag jullie op of aanmerkingen!

[skabouter]

Hmm het werkt wel, en ik kan me zo niet bedenken waarom het onveilig zou zijn.
Ik vind het alleen wel een hele lelijke oplossing en ik kan me niet voorstellen dat het je code makkelijker/logischer maakt

[Evilbee]

Ik zou hiervoor include gebruiken in plaats van include_once. Voor het geval een gebruiker iets twee keer wilt toevoegen.

Daarnaast moet je in het PHP bestand dat je include, altijd een return value opgeven. Als je dit niet doet werkt niet. En voor statische bestanden zoals .html zou ik file_get_contents gebruiken.

Als je de waardes die je in je include stop goed checkt dat ze geen config-files includen zie ik geen beveiligingsproblemen.

[disjfa]

Je hebt 1 include file die 1 variabele terug geeft. Kan, alleen het is een beetje nutteloos. Dan kan je makkelijker gewoon een leuke functie maken in de include die zaken kan retourneren.

Maar als je dit handig lijkt moet je het zeker doen.

[mithras]

Tja, het kan. Met de nodige maatregelen hoeft het niet onveilig te zijn. Waar je eerder mee zit is dat het op het eerste gezicht erg omslachtig lijkt.

Het is voor later gebruik lastig te achterhalen waarom je dit hebt gedaan. Daarom zou ik niet voor deze optie kiezen maar een elegantere methode kiezen.

[link0007]

echt mooi vind ik het niet.. en wat als ik

code:

test.php?test="><script>alert('xss')</script>

invoer? (aannemend dat het gebruikt word in een form action attribute)

[Wolf3D]

@skabouter:
Tja, lelijk .. ik vond de oplossing zo ook wel raar, maar heb geen idee hoe ik dit anders voor elkaar kan krijgen.

@Evilbee:
Include ipv include_once is idd wel een goede tip. Hoewel het niet vaak zal voorkomen dat iets 2x geinclude moet worden. Maar je weet nooit idd

In de meeste gevallen zal ik de dynamische bestanden zelf maken, aangezien klanten meestal niet met PHP overweg kunnen . Dus .. kan ik er zelf voor zorgen dat ik altijd de juiste dingen return.

@disjfa
Mijn voorbeeld was niet een beetje nutteloos, het was compleet nutteloos! Maar, de manier waarop ik het wil gaan gebruiken is volgens mij nuttiger. Het is namelijk zo dat er niet altijd een bestand geïnclude hoeft te worden. Dit kan ook in m'n CMS ingesteld worden per contentpagina.
Alleen include bestand, of include bestand gemixed met de editable content, waarbij in dat laatste geval dan via %s (of een gebruiksvriendelijke tag) kan aangegeven worden waar in de tekst het bestand weergegeven moet worden.

@ de rest:
Het voorbeeld met m'n $_GET[] var was niet hoe ik het ook wil gaan gebruiken, maar meer om te testen of het uberhaubt werkt. In eerste instantie wil ik het bijv. gebruiken voor een contactformulier, waarbij het dus $_POST vars zijn.

[Voutloos]

Wolf3D schreef op vrijdag 12 december 2008 @ 12:32:
Het voorbeeld met m'n $_GET[] var was niet hoe ik het ook wil gaan gebruiken, maar
[...]
waarbij het dus $_POST vars zijn.

Als je maar weet dat het net zo hard zeer eenvoudig manipuleerbare user input blijft.

[Wolf3D]

Yup, duidelijk. Alle input wordt gecontroleerd!

Thanks voor jullie input!

[GlowMouse]

Als jij include gebruikt en je krijgt PHP-code terug, wordt die PHP-code gewoon op jouw server uitgevoerd. Zeer onveilig dus.

[Verwijderd]

De vorm is sowieso foeilelijk, maar als je dit wilt kun je beter file_get_contents gebruiken in plaats van include_once om te voorkomen dat eventuele PHP-code in het bestand uitgevoerd wordt.

[Evilbee]

Verwijderd schreef op vrijdag 12 december 2008 @ 17:32:
De vorm is sowieso foeilelijk, maar als je dit wilt kun je beter file_get_contents gebruiken in plaats van include_once om te voorkomen dat eventuele PHP-code in het bestand uitgevoerd wordt.

Tenzij de php-bestanden die je include zelf hebt gemaakt en op je eigen server staan. Zodra je bestanden via http gaat includen kan je het beste file_get_contents gebruiken.

offtopic:
Hoi ex-collega!

[.oisyn]

Ik snap de laatste 3 reacties niet. file_get_contents() doet overduidelijk niet wat de TS wilt, en daarnaast wordt er niets geinclude van een andere server.

Wolf3D schreef op vrijdag 12 december 2008 @ 12:32:
@skabouter:
Tja, lelijk .. ik vond de oplossing zo ook wel raar, maar heb geen idee hoe ik dit anders voor elkaar kan krijgen.

Wat probeer je precies te doen dan? Waar komt die include.php vandaan? Want er zijn 1001 manieren om het anders aan te pakken.

[ Voor 5% gewijzigd door .oisyn op 12-12-2008 21:03 ]

[Patriot]

GlowMouse schreef op vrijdag 12 december 2008 @ 15:14:
Als jij include gebruikt en je krijgt PHP-code terug, wordt die PHP-code gewoon op jouw server uitgevoerd. Zeer onveilig dus.

Huh? Hoe bedoel je? Als je PHP-code in die GET variabele stopt dan voert PHP dat echt niet uit hoor.

Aan de TS een tip: Als je wilt weten of een oplossing goed is, kun je beter je probleem uitleggen en dan die oplossing erbij. Op die manier kan iemand naast (als hij niet goed is) je oplossing afkeuren ook met een (in zijn of haar ogen) betere oplossing komen.

[Wolf3D]

.oisyn schreef op vrijdag 12 december 2008 @ 21:03:
Ik snap de laatste 3 reacties niet. file_get_contents() doet overduidelijk niet wat de TS wilt, en daarnaast wordt er niets geinclude van een andere server.

Inderdaad. Alle includes staan op de eigen server en zijn door mij zelf gemaakt. Voor de veiligheid zijn deze bestanden ook niet via het CMS te uploaden maar moet dit met de hand op de server gezet worden.

.oisyn schreef op vrijdag 12 december 2008 @ 21:03:
Wat probeer je precies te doen dan? Waar komt die include.php vandaan? Want er zijn 1001 manieren om het anders aan te pakken.

Die include.php is dus een variabele naam. Dus eigenlijk $include.php in mijn geval. Het CMS heeft een input veld voor de content van de pagina, OF er kan gekozen worden om een bestand te includen. Dit bijv. omdat er altijd ergens een dynamische pagina nodig is welke niet via een teksteditor gemaakt kan worden. Dus voor die gevallen is het mogelijk een bestandsnaam op te geven. Deze bestanden plaats ik allemaal in een vaste map. De gebruiker kan dan alleen bijvoorbeeld 'contact' opgeven, en dan wordt er automatisch '/content_files/include/contact.php' van gemaakt. Relatief veilig lijkt me, aangezien alleen al bestaande bestanden in een bepaalde map geinclude kunnen worden. Daarnaast is het CMS natuurlijk alleen bereikbaar voor gebruikers met een inlogcode.

Nu is het probleem dat het nu het een OF het andere is. Dus of tekst via teksteditor OF een geinclude bestand. Maar nu heb ik een contact pagina, met een stukje adresinformatie, en een contactformulier.
Momenteel is het dus zo dat ik de hele pagina moet verplaatsen naar het include bestand, wat dan ook meteen inhoud dat het stukje adresinformatie niet (door de gebruiker) aan te passen is.
Dus leek me de makkelijkste oplossing om het te combineren zodat het niet teksteditor OF include is, maar beide. In dat geval wil ik dan wel aan kunnen geven waar de include terecht komt. Bijv. eerst de adresinformatie en dan het formulier via include, of eerst formulier en dan adresinformatie.
En zo kwam ik bij het idee om via de teksteditor een tag in te vullen die ervoor zorgt dat op die plek het te includen bestand weergegeven wordt.

Zo kwam ik bij bovenstaande oplossing...

Hopelijk is mijn gedachtegang nu iets duidelijker.

[MBV]

Ik volg je echt totaal niet. Ik zou, als ik ongeveer jouw architectuur aan zou houden, zoiets doen:
origineel bestand:

PHP:

include($variabele_include);
$string = "bladibla ";
$string .= getOutput();
$string .= " bladibla";

variabele include:

PHP:

function getOutput() {
  return "included";
}

Je maakt dan dus een plugin-architectuur, waarbij elke plugin maar 1 functie hoeft te implementeren. En voor het standaard-geval maak je een standaard-plugin, zodat je altijd een plugin gebruikt om de output te krijgen. Dat is hoe Joomla het ongeveer doet.

Ik denk niet dat dit de goede manier is. Probleem 1: je bent je eigen CMS aan het maken. Waarom niet standaard-software als Joomla (of iets beters ) gebruiken?
Probleem 2: hoe ga je het in de GUI 'uitleggen'?
Probleem 3: hoe krijg je het veilig?

Wat gebeurt er trouwens als ik ../../../passwd als plugin ga gebruiken in jouw geval? PHP zal, voor de printf wordt uitgevoerd, eerst het resultaat van de include op het scherm zetten namelijk Je zal dus iets moeten normaliseren aan je input.

[ Voor 3% gewijzigd door MBV op 13-12-2008 14:26 ]

[torp]

In mijn eigen simpele cms-je dat werkt met ubb-code, heb ik voor het toevoegen van sommige functies een module-tag gebruikt. Gewone ubb-tags worden voor het versturen naar de browser omgezet in html-code, maar bij de tag [module=contactformulier] wordt gekeken of een bestandje genaamd 'contactformulier.txt' in de map 'modules' bestaat. Zoja, dan wordt hij op die plek ge-include. Ik heb die modules zelf gemaakt en op de server gezet. Door de naamgeving kan de klant begrijpen waarvoor de tag bedoeld is.

Voorbeeld: de ingevoerde tekst in het cms zou er dan alsvolgt uit kunnen zien:

U bent altijd welkom op het adres Hoofdstraat 1. Wij zijn geopend van 9 tot 5. [bold]Gelieve wel rekening te houden met lange wachttijden![/bold]

Wij raden u echter aan per email contact op te nemen. U wordt dan sneller geholpen want email heeft voorrang! Gebruik daarvoor onderstaand formulier. Vul alle velden in en klik op 'verstuur'.

[module=contactformulier]

Note: voor de duidelijkheid even bold-tag gebruikt ipv. b-tag.

[ Voor 54% gewijzigd door torp op 13-12-2008 15:08 ]

[MBV]

In dat geval zou ik de UBB code afhandelen in een 'gewone' functie, en de modules op de manier zoals ik dat in mijn vorige bericht voorstelde. Wat is in jouw ogen het grote voordeel van de Printf hack?

[torp]

Ik vermoed dat je mij verwart met de topicstarter... en ik gebruik file_get_contents voor het includen.