---

Jeg arbejder på et script, som skal teste, om en variabel,
$code, indeholder enten en "plain text" eller PHP-kode
(eller evt. begge dele). Formålet er at afgøre, om
variablens indhold skal vises med PHP-highlighting eller ej.

Pt. bruger jeg flg. test, men er utilfreds med den, da den
ikke genkender alle PHP-scripts. F.eks. er det ikke alle
scipts, som starter med <?php..

if (strpos($code, "?php"))....

Hvordan ville I udføre denne test?

mvh Per

---

Per Riber skrev Tirsdag den 23. august 2005 22:18 i beskeden
<d50ng15d52vokm26q6t90ov2njg5cufa0r@4ax.com> i gruppen
dk.edb.internet.webdesign.serverside.php:
> Jeg arbejder på et script, som skal teste, om en variabel,
> $code, indeholder enten en "plain text" eller PHP-kode
> (eller evt. begge dele). Formålet er at afgøre, om
> variablens indhold skal vises med PHP-highlighting eller ej.
> Pt. bruger jeg flg. test, men er utilfreds med den, da den
> ikke genkender alle PHP-scripts. F.eks. er det ikke alle
> scipts, som starter med <?php..
> if (strpos($code, "?php"))....
> Hvordan ville I udføre denne test?
> mvh Per

Du kan vælge at teste på "<?" og "?>"

Ligeledes kan du vælge [hvis det er en dansk Blog f.eks.], at alle beskeder
med ordet "echo" erstattes med "ekko" - så har du en ekstra kontrol...

--
Med venlig hilsen
Henrik Blunck
Vil du vide mere om Linux - http://www.linux-svar.dk
Oversættelse af manualer m.v. - http://www.ikt-strategi.dk

---

Tue, 23 Aug 2005 22:45:26 +0200 skrev Henrik Blunck
<h_blunck@gmx.net>:

>Du kan vælge at teste på "<?" og "?>"

Okay, det vil jeg forsøge.

>Ligeledes kan du vælge [hvis det er en dansk Blog f.eks.], at alle beskeder
>med ordet "echo" erstattes med "ekko" - så har du en ekstra kontrol...

Går tricket med at ændre "echo" til "ekko" ud på at
forhindre ondsindede brugere i at få tilsendt variabler,
f.eks. dbpasswords, fra PHP-programmerne..?

Jeg forventer at starte en blog, men er ikke nået så vidt
endnu. Lige nu er det http://pastebin.priber.dk, jeg pusler
med. Hvis du har tid og lyst, er du velkommen til at tjekke
sourcekoden. Jeg vil selvfølgelig meget gerne høre om det,
hvis der er sikkerhedshuller i programmet..

mvh Per

---

Per Riber skrev Tirsdag den 23. august 2005 23:26 i beskeden
<sc4ng11u91ireeqdb2mibisljst5mkjtha@4ax.com> i gruppen
dk.edb.internet.webdesign.serverside.php:
> Tue, 23 Aug 2005 22:45:26 +0200 skrev Henrik Blunck
> <h_blunck@gmx.net>:
>>Du kan vælge at teste på "<?" og "?>"
> Okay, det vil jeg forsøge.

Det lyder fornuftigt.

>>Ligeledes kan du vælge [hvis det er en dansk Blog f.eks.], at alle
>>beskeder med ordet "echo" erstattes med "ekko" - så har du en ekstra
>>kontrol...
> Går tricket med at ændre "echo" til "ekko" ud på at
> forhindre ondsindede brugere i at få tilsendt variabler,
> f.eks. dbpasswords, fra PHP-programmerne..?

Lige nøjagtig.

> Jeg forventer at starte en blog, men er ikke nået så vidt
> endnu. Lige nu er det http://pastebin.priber.dk, jeg pusler
> med. Hvis du har tid og lyst, er du velkommen til at tjekke
> sourcekoden. Jeg vil selvfølgelig meget gerne høre om det,
> hvis der er sikkerhedshuller i programmet..
> mvh Per

Du kan læse mere herom på http://www.hackademi.com/ Jeg synes lektion 2 om
det at beskytte sin gæstebog var særdeles interessant.

--
Med venlig hilsen
Henrik Blunck
Vil du vide mere om Linux - http://www.linux-svar.dk
Oversættelse af manualer m.v. - http://www.ikt-strategi.dk

---

Wed, 24 Aug 2005 00:07:49 +0200 skrev Henrik Blunck
<h_blunck@gmx.net>:


>Du kan læse mere herom på http://www.hackademi.com/ Jeg synes lektion 2 om
>det at beskytte sin gæstebog var særdeles interessant.

Tak for tippet, Henrik.

mvh Per

---

Per Riber skrev Onsdag den 24. august 2005 00:16 i beskeden
<q08ng11j55a53j1brkvd8nbca2ti7q9npt@4ax.com> i gruppen
dk.edb.internet.webdesign.serverside.php:
>>Du kan læse mere herom på http://www.hackademi.com/ Jeg synes lektion 2 om
>>det at beskytte sin gæstebog var særdeles interessant.
> Tak for tippet, Henrik.
> mvh Per

Velbekomme.

--
Med venlig hilsen
Henrik Blunck
Vil du vide mere om Linux - http://www.linux-svar.dk
Oversættelse af manualer m.v. - http://www.ikt-strategi.dk

---

On Wed, 24 Aug 2005 00:07:49 +0200, Henrik Blunck <h_blunck@gmx.net>
wrote:

>Du kan læse mere herom på http://www.hackademi.com/ Jeg synes lektion 2 om
>det at beskytte sin gæstebog var særdeles interessant.

Hm, bekymrende at man skal downloade .exe-filer for at se indholdet.
Det virker ikke ligefrem som god brugeropdragelse.

... og "Fatal error: Allowed memory size of 8388608 bytes exhausted
(tried to allocate 46080 bytes) in
/usr/home/user1019/hackademi.com/htdocs/pathway.php on line 99" tyder
vist på, at de ikke ligefrem gør i at sikre deres egen installation.

Der er ingen grund til at vise fejl på et produktionssite. Brugeren
har intet at bruge fejlen til (ud over måske at lære noget om
installationen), og administratoren bliver ikke informeret.

Vi må så håbe, at diverse PHP-fejlrettelser er blevet backportet - og
at de får lidt mere styr på magic_quotes

--
- Peter Brodersen

---

Peter Brodersen skrev Onsdag den 24. august 2005 16:31 i beskeden
<dei0e3$23f$1@news.klen.dk> i gruppen
dk.edb.internet.webdesign.serverside.php:
> On Wed, 24 Aug 2005 00:07:49 +0200, Henrik Blunck <h_blunck@gmx.net>
> wrote:
>>Du kan læse mere herom på http://www.hackademi.com/ Jeg synes lektion 2 om
>>det at beskytte sin gæstebog var særdeles interessant.
> Hm, bekymrende at man skal downloade .exe-filer for at se indholdet.
> Det virker ikke ligefrem som god brugeropdragelse.

Hvorfor dog ikke det? Du kan da også finde steder hvor ting f.eks. er pakket
i Zip-formatet, og hvis det er virus-risikoen du tænker på, kan man
fremhæve der også kan være virus i grafik.

Tror nu nærmere det er for at undgå piratkopiering at der er valgt et e-bogs
format med beskyttelse.

> .. og "Fatal error: Allowed memory size of 8388608 bytes exhausted
> (tried to allocate 46080 bytes) in
> /usr/home/user1019/hackademi.com/htdocs/pathway.php on line 99" tyder
> vist på, at de ikke ligefrem gør i at sikre deres egen installation.

Hvad tænker du på her? Jeg får ikke denne fejl, så jeg er ikke helt
med...

> Der er ingen grund til at vise fejl på et produktionssite. Brugeren
> har intet at bruge fejlen til (ud over måske at lære noget om
> installationen), og administratoren bliver ikke informeret.
> Vi må så håbe, at diverse PHP-fejlrettelser er blevet backportet - og
> at de får lidt mere styr på magic_quotes

Jeg er meget nysgerrig...

--
Med venlig hilsen
Henrik Blunck
Vil du vide mere om Linux - http://www.linux-svar.dk
Oversættelse af manualer m.v. - http://www.ikt-strategi.dk

---

On Thu, 25 Aug 2005 01:09:15 +0200, Henrik Blunck <h_blunck@gmx.net>
wrote:

>> Hm, bekymrende at man skal downloade .exe-filer for at se indholdet.
>> Det virker ikke ligefrem som god brugeropdragelse.
>Hvorfor dog ikke det? Du kan da også finde steder hvor ting f.eks. er pakket
>i Zip-formatet, og hvis det er virus-risikoen du tænker på, kan man
>fremhæve der også kan være virus i grafik.

Det er som sagt helt sikkert dårlig brugeropdragelse at lære folk, at
dokumenter er noget, der kommer i .exe-filer (uanset om de så først er
pakket som zipfil eller ej).

Det med at "der kan være virus i grafik" er en frygtelig
popularisering, hvilket medier og specielt antivirus-producenter ofte
fremhæver og går i selvsving over. Der kan være fejl i enkelte
programmers fremvisning af et billede, og fejl vil så kun komme til
udtryk i ikke-opdaterede udgaver i de få programmer.

Med andre ord, hvis man har et opdateret billedvisnings-program, bør
der ikke være nogen bekymring. Der er en øvre grænse for hvad, der kan
se.

Den øvre grænse for en .exe-fil er ens brugerrettigheder. Der er
vitterligt ingen grund til at noget tekst skal have adgang til hele
ens brugerprofil.

>Tror nu nærmere det er for at undgå piratkopiering at der er valgt et e-bogs
>format med beskyttelse.

Det går bare ikke hånd i hånd med et site, der påstår at forsøge at
lære folk om sikkerhed.

>Hvad tænker du på her? Jeg får ikke denne fejl, så jeg er ikke helt
>med...

Jeg oplevede den på enkelte sider, bare ved at klikke lidt frem og
tilbage. Fejl kan ske, men der er ingen grund til at kaste dem ud i
ansigtet på brugere.

>> Vi må så håbe, at diverse PHP-fejlrettelser er blevet backportet - og
>> at de får lidt mere styr på magic_quotes
>Jeg er meget nysgerrig...

www.hackademi.com kører tilsyneladende PHP 4.3.8. Vi må håbe at
relevante sikkerhedspatches er blevet backportet til den udgave.
magic_quotes lader til at tilføje backslashes på søgeordet, og der
kommer et ekstra sæt slashes på ved google-teksten - enten fordi der
laves et internt http-request eller fordi der bruges addslashes() i
stedet for stripslashes().

--
- Peter Brodersen

---

Peter Brodersen formulated on torsdag :
> Det med at "der kan være virus i grafik" er en frygtelig
> popularisering, hvilket medier og specielt antivirus-producenter ofte
> fremhæver og går i selvsving over. Der kan være fejl i enkelte
> programmers fremvisning af et billede, og fejl vil så kun komme til
> udtryk i ikke-opdaterede udgaver i de få programmer.

Der er lavet en "proof of concept" virus i JPEG formatet (svjh), altså
et bevis på at det kan lade sig gøre.

--
Henrik Stidsen - http://henrikstidsen.dk/

---

On 2005-08-25, Henrik Stidsen <nntpspam@hs235.dk> wrote:
> Peter Brodersen formulated on torsdag :
>> Det med at "der kan være virus i grafik" er en frygtelig
>> popularisering, hvilket medier og specielt antivirus-producenter ofte
>> fremhæver og går i selvsving over. Der kan være fejl i enkelte
>> programmers fremvisning af et billede, og fejl vil så kun komme til
>> udtryk i ikke-opdaterede udgaver i de få programmer.
>
> Der er lavet en "proof of concept" virus i JPEG formatet (svjh), altså
> et bevis på at det kan lade sig gøre.

En virus er et stykke kode, der reproducerer sig selv og dermed opnår
spredning. Man kan som Peter skriver ganske rigtigt være ude for, at
programmeringsfejl i diverse biblioteker og programmer gør, at en særlig
bitstreng (f.eks. en manipuleret JPEG fil) udnytter disse
programmeringsfejl til at opnå udførsel af arbitrær kode (og dermed
virus kode).

Men en angriber kan _ikke_ være sikker på, at modtageren viser JPEG
filen i et sårbart program. Altså kan jeg være ganske sikker på, at lige
gyldigt hvilken JPEG fil du sender mig, vil jeg kunne fremvise den uden
den store risiko, med mindre du har fundet en sårbarhed i min fremviser,
som endnu ikke er rettet hos producenten. Hvis man ser historisk på
det, er det ganske sjældent, at der bliver fundet den slags sårbarheder
og de bliver ofte rettet meget hurtigt.

For eksekverbare filer (.exe) gælder der derimod, at de er ment som at
skulle indeholde kode og derfor har jeg ingen ide om, hvad en
eksekverbar fil vil gøre ved mit system, hvis jeg kører den. De kan være
inficerede med virus, ligge en bagdør ind i mit system, ændre min
browser, sende mine netbank data ud på Internettet, eller hvad fantasien
og de rettigheder jeg som bruger kører med ellers tillader.

Din analogi med billeder og eksekverbare filer er således ikke holdbar.
Og jeg er ganske enig med Peter i, at man rimeligvis kan stille
spørgsmålstegn ved seriøsiteten af et sikkerhedssite, der beder brugerne
om at køre en eksekverbar fil for at fremvise noget, der principielt
bare kunne stå på deres hjemmeside. Hvorvidt motivet så er forsøg på at
undgå piratkopiering eller andet, er forsåvidt underordnet.

Endelig finder jeg det bemærkelsesværdigt, at der ikke er nogen
information om, hvem der står bag siden udover navnet "Chill".

--
Med venlig hilsen
- Jacob Atzen

---

25 Aug 2005 11:39:55 GMT skrev Jacob Atzen <jacob@aub.dk>:

>bare kunne stå på deres hjemmeside. Hvorvidt motivet så er forsøg på at
>undgå piratkopiering eller andet, er forsåvidt underordnet.
>
>Endelig finder jeg det bemærkelsesværdigt, at der ikke er nogen
>information om, hvem der står bag siden udover navnet "Chill".

Det er Britt og Cyril Malka, som står bag siden. Den er
hosted på et webhotel i Frankrig, hvor de bor.

Da jeg ikke er nogen PHP-ørn, kan ikke udtale mig om
kvaliteten af deres kurser, men som ren amatør synes jeg, at
sitet er lovligt kommercielt for mig. Jeg får absolut intet
udbytte af siden, medmindre jeg finder tegnebogen frem.

Desuden ville jeg foretrække info på en form, som IKKE
medfører distribution via Windows .exe-filer. Jeg tror på,
at Unix/Linux-folk har større viden på området, og de ville
næppe vælge netop dét format.

Ergo: Jeg vil se mig om efter andre steder at lære noget om
PHP-sikkerhed Har du et godt bud..?

mvh Per

---

On 2005-08-25, Per Riber <none@nospam.invalid> wrote:
> Da jeg ikke er nogen PHP-ørn, kan ikke udtale mig om
> kvaliteten af deres kurser, men som ren amatør synes jeg, at
> sitet er lovligt kommercielt for mig. Jeg får absolut intet
> udbytte af siden, medmindre jeg finder tegnebogen frem.

Som professionel er sitet også for kommercielt til mig. Jeg har ingen
ide om kvaliteten af deres artikler, hvorfor jeg ikke kan se nogen grund
til at bruge penge på det.

> Desuden ville jeg foretrække info på en form, som IKKE
> medfører distribution via Windows .exe-filer. Jeg tror på,
> at Unix/Linux-folk har større viden på området, og de ville
> næppe vælge netop dét format.

Ens foretrukne OS behøves jo ikke have indflydelse på ens kompetencer
indenfor sikkerhed.

> Ergo: Jeg vil se mig om efter andre steder at lære noget om
> PHP-sikkerhed Har du et godt bud..?

David Wheeler har skrevet en bog om sikker programmering som han har
gjort tilgængelig på nettet:

<http://www.dwheeler.com/secure-programs/>

Den har et lille afsnit om PHP, men derudover er der sikkert meget
inspiration at hente i bogens andre afsnit. Meget sikkerhedstænkning er
jo generelt. Jeg har ikke selv læst bogen, så jeg skal ikke kunne sige,
hvor god eller dårlig den er, men jeg har fået den anbefalet af folk jeg
anser for kompetente.

Derudover findes der et hav af artikler på nettet om forskellige
angrebsformer og hvordan man sikrer sig mod dem. Jeg kan umiddelbart kun
komme i tanke om to former: SQL injection og cross site scripting.

En artikel jeg selv synes var ganske interessant er:

<http://shiflett.org/articles/foiling-cross-site-attacks>

Generelt kan man sige, at al data der kommer ind i din applikation
udefra skal checkes og valideres. Det handler om at finde ud af, hvordan
en angriber kan tænkes at påvirke dit system og sikre, at dette ikke kan
lade sig gøre. En normal PHP webapplikation kan kun påvirkes igennem
$_GET, $_POST og $_COOKIE. Det er altså data fra disse tre kilder, du
skal sikre.

Hvis du ligger på en usikker server, er det ligeledes vigtigt at tage
køretidsmiljøet med i betragtning. F.eks. kan sessionsvariable give
mulighed for angreb på delte servere. Peter Brodersen har nogen
eksempler på dette på sin hjemmeside:

<http://stock.ter.dk/session.php>

--
Med venlig hilsen
- Jacob Atzen

---

25 Aug 2005 13:41:08 GMT skrev Jacob Atzen <jacob@aub.dk>:

>Ens foretrukne OS behøves jo ikke have indflydelse på ens kompetencer
>indenfor sikkerhed.

Du har ret. Jeg er da også selv Windowsbruger, både
herhjemme og på arbejde, men egentlig mere af nød end af
lyst. Jeg er/var OS/2-freak i 90'erne

Man har sikkert valgt at udgive kurserne som .exe, fordi de
er nemmest at håndtere for flertallet af sitets målgruppe.

><http://www.dwheeler.com/secure-programs/>
><http://shiflett.org/articles/foiling-cross-site-attacks>

>Hvis du ligger på en usikker server, er det ligeledes vigtigt at tage

Er man på en usikker server, når safe mode er frakoblet..?

><http://stock.ter.dk/session.php>

Mange tak for forklaringerne og dine links. Jeg har skimmet
dem alle, de ser rigtig spændende ud og er naturligvis
indlemmet i min bogmærkesamling til senere studier.

mvh Per

---

On 2005-08-25, Per Riber <none@nospam.invalid> wrote:
> Man har sikkert valgt at udgive kurserne som .exe, fordi de
> er nemmest at håndtere for flertallet af sitets målgruppe.

Man skulle tro, at et link til en hjemmeside var nemmere end at skulle
hente og køre en .exe fil. Men det er nok bare mig der er gammeldags

> Er man på en usikker server, når safe mode er frakoblet..?

Man er på en usikker server, hvis man ikke selv administrerer, hvem der
har adgang til den. Det vil f.eks. sige at webhoteller per definition er
usikre efter den definition.

--
Med venlig hilsen
- Jacob Atzen