Foarte ciudat php include comportamentul ..

I am experiencing some very strange behavior when including a PHP file.
I need to load a script that is not on the same domain as the page that will be calling it.

I have already created a system that works using cURL, but I just recently found out that many of the sites that will need to have access to this script, do not have cURL installed. I did, however, notice that these sites have allow_url_fopen set to on. With this knowledge I got started creating a new system that would let me just include the script on the remote site.

Just testing this out, I coded the script test.php as follows:

<?php 
echo("test");
?>

Am inclus acest script pe pagina de la distanță utilizând:

<?php
include("http://mydomain.com/script.php");
?>

and it works no problem and "test" is printed at the top of the page.

However, if I add a function to the script and try to call the function from the page, it crashes.
To make it worse, this site has PHP errors turned off and I have no way of turning it on.

To fully make sure that I didn't just mess up the code, I made my test.php look like this:

<?php
function myfunc()
{
return "abc";
}
?>

Apoi, pe pagina care include fișierul:

<?php 
include("http://mydomain.com/script.php");
echo(myfunc());
?>

Și se prăbușește. Orice idei ar fi foarte apreciate.

0

3 răspunsuri

Cred că PHP-ul http://mydomain.com/script.php este interpretat de către serverul web al mydomain.com. Tot ce sunteți inclusiv este rezultatul al acelui script. Pentru un simplu echo ("test") , acesta este "test". Funcțiile nu produc nici o ieșire și nu sunt disponibile pentru scriptul inclusiv . Confirmați acest lucru prin simpla vizitare a http://mydomain.com/script.php în browserul dvs. și vedeți ce obțineți. Ar trebui să oprești mydomain.com să interpreteze fișierul PHP și să-l întoarcă ca text pur.

But: this sounds like a bad idea to begin with. Cross-domain includes are an anti-patterns. Not only does it open you up to security problems, it also makes every page load unnecessarily slow. If cross-domain inclusions is the answer, your question is wrong.

0
adăugat
Eventualele exploatări includ: în primul rând, codul pe care îl includeți, prin definiție, este vizibil public. Nu știu pentru ce folosiți această tehnică, dar de multe ori oamenii încearcă să păstreze anumite fișiere "secrete" pe serverul lor, ceea ce are în acest caz efectul exact opus. Alte exploatări: atacuri DNS împotriva serverului care redirecționează cererile la mydomain.com în altă parte, permițând în mod convenabil injectarea de coduri. Sau doar deturnarea serverului mydomain.com în primul rând.
adăugat autor deceze, sursa
Întârzierea adăugată ar face ca aceasta să nu fie o soluție viabilă. Celelalte detalii adaugă doar mai multe puncte minus. Și nu știu ce va fi inclus în fișierul final, dar orice doriți să includeți include , va trebui să fie transferat prin HTTP în text clar și oricine poate merge pur și simplu la adresa URL pentru a vedea codul care va fi inclus. Creați un API care transferă numai datele necesare, dacă este cazul.
adăugat autor deceze, sursa
Depinde de ce vrei să faci cu curl. Nu o utilizați pentru a prelua și a executa un cod arbitrar peste "net", indiferent dacă faceți acest lucru folosind include sau curl nu contează.
adăugat autor deceze, sursa
Da, asta trebuie să fie problema. Îmi dau seama că nu este o idee foarte bună de a include intersecțiile, dar mă confrunt cu greu să văd cum ar putea fi exploatată în cazul meu. Care este diferența dintre un server care cheamă scenariul meu și cineva care tocmai a încărcat scriptul în browserul său? Din ceea ce pot spune, marele nu este setarea permis_url_fopen pe primul loc, ceea ce nu fac. Clientul are deja acest set pe serverul lor. Văd cum ar putea face ca paginile să se încarce mai lent decât de obicei. Multumesc pentru ajutor!
adăugat autor Scott Haley, sursa
Dacă aș reuși să păstrez ceva "secret" în afara acestui scenariu special? Scriptul va trage informații dintr-o bază de date mysql, dar dacă pun codul pentru a se conecta la baza de date într-un fișier separat și include scriptul, atunci informațiile respective nu vor mai fi ascunse? Și în afară de informațiile care se conectează direct la baza mea de date, informațiile pe care scenariul le va trage nu sunt deloc "secrete" și nici nu ar fi utile nimănui. DNS exploatează singure suficiente pentru a face ca aceasta să nu fie o soluție viabilă?
adăugat autor Scott Haley, sursa
Bine, voi recunoaște că am învins și am renunțat la această metodă. : P Există probleme când folosiți cURL pentru a face acest lucru? Sau este ceva ce trebuie să fiu atent atunci când folosesc cURL ca asta?
adăugat autor Scott Haley, sursa
Voi trece variabilele pe care serverul meu le-ar utiliza pentru a extrage informații dintr-o bază de date și a le trimite înapoi.
adăugat autor Scott Haley, sursa

Voi includeți ieșirea din partea clientului din test.php, mai degrabă decât codul sursă de pe server. Redenumiți test.php la test.phpc pentru a împiedica executarea scriptului. Cu toate acestea, acest lucru este periculos din punct de vedere al securității.

0
adăugat

Nu este un comportament ciudat, dar din moment ce încărcați fișierul pe Internet (rețineți în acest caz World Wide Web), fișierul este interpretat înainte de a fi trimis la funcția de includere.

Din moment ce scriptul este interpretat, nu vor fi vizibile funcții, ci doar rezultatul scriptului.

Fie încărcați-o peste FTP, fie creați un API pentru funcții.

0
adăugat
Ah, bine, are sens. Voi analiza crearea unui API. Mulțumiri!
adăugat autor Scott Haley, sursa
PHP România, Moldova
PHP România, Moldova
173 participanți

Vorbim despre Yii, Laravel, Symphony, MySQL, PgSQL, WP, OpenCart... Pentru confort, opriți notificările. Parteneri: https://ciupacabra.com @js_ro @node_ro @python_ro @seo_ro @Romania_Bot Offtop: @holywars_ro Joburi: @php_job @Grupuri_IT