---

Hej,

Jeg har en del erfaring med C-programmering, men åbenbart ikke nok...

Er der nogen der kan fortælle mig hvordan/om man kan interface en html-form
med noget
C-kode som gemmer oplysningerne fra en form i en hjemmelavet database?

Og hvordan fungerer det den anden vej? Altså hvordan modtager en form
oplysninger
fra en database via et C-program?

Jeg prøvede for sjov skyld, at sætte en FORM ACTION = "\cgi-bin\mitCprg.exe"
og da jeg trykkede SUBMIT poppede der et vindue op hvor jeg blev spurgt om
jeg ønskede
at eksekvere filen....Jeg vil dog gerne have at filen eksekveres automatisk
og uden brugeren kan se det....

Jeg ved at man kan programmere ovenstående i PHP sammen med en MySql
database, men jeg er som sagt interesseret i at vide hvordan man laver en
ren HTML + C-løsning.


Mange tak på forhånd.

---

Den 18-07-07 12.20 skrev John Eriksen følgende:

> Jeg prøvede for sjov skyld, at sætte en FORM ACTION = "\cgi-bin\mitCprg.exe"
> og da jeg trykkede SUBMIT poppede der et vindue op hvor jeg blev spurgt om
> jeg ønskede at eksekvere filen

Er du sikker på, at den ville blive eksekveret på serveren og ikke på
brugerens computer? Jeg kan forestille mig, at det er en almindelig
download-dialogboks, du får åbnet.

For at få programmet eksekveret på serveren, skal du fortælle din
webserver, at exe-filer i cgi-bin gerne må eksekveres på serveren.

--
Mvh. Kim Ludvigsen
Tips og tricks til sikkerhedskopiering.
http://kimludvigsen.dk

---

"John Eriksen" <john@virkerikke.dk> writes:

> Er der nogen der kan fortælle mig hvordan/om man kan interface en html-form
> med noget
> C-kode som gemmer oplysningerne fra en form i en hjemmelavet database?
>
> Og hvordan fungerer det den anden vej? Altså hvordan modtager en form
> oplysninger
> fra en database via et C-program?

C-programmet modtager data fra webformularen ved at blive kaldt med
et bestemt indhold i nogle envirenment variable og eventuelt med noget
data på stdin. Ved GET-formulare bliver data leveret i environment
variablem QUERY_STRING og ved POST bliver de givet via stdin.

C-programmet sender så data ved at skrive en HTML-side ud på
stdout. (Eller hvilket type data programmet nu skal levere)

> Jeg prøvede for sjov skyld, at sætte en FORM ACTION = "\cgi-bin\mitCprg.exe"
> og da jeg trykkede SUBMIT poppede der et vindue op hvor jeg blev spurgt om
> jeg ønskede
> at eksekvere filen....Jeg vil dog gerne have at filen eksekveres automatisk
> og uden brugeren kan se det....

Det er fordi din webserver ikke forsøger at udfører programmet som et
cgi-program, men bare sender selve programmet som en fil. Det vinduet
foreslår er at du kører programmet lokalt på din computer.

At få din webserver til at udfører filen som et cgi-script, skal du
sætte op på serveren.

> Jeg ved at man kan programmere ovenstående i PHP sammen med en MySql
> database, men jeg er som sagt interesseret i at vide hvordan man laver en
> ren HTML + C-løsning.

Læs http://www.cs.tut.fi/~jkorpela/forms/cgic.html

men det er lettere bare at lade være...

//Makholm

---

John Eriksen wrote:

> Jeg har en del erfaring med C-programmering, men åbenbart ikke nok...
>
> Er der nogen der kan fortælle mig hvordan/om man kan interface en html-form
> med noget
> C-kode som gemmer oplysningerne fra en form i en hjemmelavet database?

Ja. Det er der masser af eksempler på.

Det almindelige interface, du skal kende, er CGI.

> Og hvordan fungerer det den anden vej? Altså hvordan modtager en form
> oplysninger
> fra en database via et C-program?

Når du har undersøgt CGI ovenfor vil du opdage at det også kan bruges
til den opgave.

> Jeg prøvede for sjov skyld, at sætte en FORM ACTION = "\cgi-bin\mitCprg.exe"
> og da jeg trykkede SUBMIT poppede der et vindue op hvor jeg blev spurgt om
> jeg ønskede
> at eksekvere filen....Jeg vil dog gerne have at filen eksekveres automatisk
> og uden brugeren kan se det....

Du skal have en webserver imellem dig og dit c-program. Webserveren
"snakker" så CGI med dit program.

> Jeg ved at man kan programmere ovenstående i PHP sammen med en MySql
> database, men jeg er som sagt interesseret i at vide hvordan man laver en
> ren HTML + C-løsning.

Start med at finde et lille cgi-program skrevet i c - der må findes et
have af dem på nettet.

Mvh. Michael.

---

On Wed, 18 Jul 2007 18:52:02 +0200
Michael Zedeler <michael@zedeler.dk> wrote:

>
> Du skal have en webserver imellem dig og dit c-program. Webserveren
> "snakker" så CGI med dit program.
>
Da ikke nødvendigvis. Hvis opgaven er yderst begrænset, kan man
relativt let selv implementere en http-1.0 server selv i ens program.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

Michael Rasmussen wrote:
> On Wed, 18 Jul 2007 18:52:02 +0200
> Michael Zedeler <michael@zedeler.dk> wrote:
>
>> Du skal have en webserver imellem dig og dit c-program. Webserveren
>> "snakker" så CGI med dit program.
>>
> Da ikke nødvendigvis. Hvis opgaven er yderst begrænset, kan man
> relativt let selv implementere en http-1.0 server selv i ens program.

Ja. Med lidt snilde kan man også skrive et operativsystem, så man
slipper for for den ekstra dødvægt

Mvh. Michael.

---

On Wed, 18 Jul 2007 12:20:15 +0200
"John Eriksen" <john@virkerikke.dk> wrote:

>
> Er der nogen der kan fortælle mig hvordan/om man kan interface en
> html-form med noget
> C-kode som gemmer oplysningerne fra en form i en hjemmelavet database?
>
Kik eventuelt her: http://libcgi.sourceforge.net/

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

On Thu, 19 Jul 2007 19:36:59 +0200
Michael Zedeler <michael@zedeler.dk> wrote:

>
> Ja. Med lidt snilde kan man også skrive et operativsystem, så man
> slipper for for den ekstra dødvægt
>
Det er jo ikke altid, der er behov for en full blown webserver.
http://www.gnetlibrary.org/

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

Michael Rasmussen wrote:
> On Thu, 19 Jul 2007 19:36:59 +0200
> Michael Zedeler <michael@zedeler.dk> wrote:
>
>> Ja. Med lidt snilde kan man også skrive et operativsystem, så man
>> slipper for for den ekstra dødvægt
>
> Det er jo ikke altid, der er behov for en full blown webserver.
> http://www.gnetlibrary.org/

Mnjaeh. Det er bare nemt at komme til at eksponere et program som han
nogle ubehagelige sikkerhedshuller, webserveren ellers vil fange for en.
Samtidig er det i mange sammenhænge sværere at vedligeholde og administrere.

Mvh. Michael.

---

Den Sun, 22 Jul 2007 17:14:12 +0200 skrev Michael Zedeler:
> Michael Rasmussen wrote:
>> On Thu, 19 Jul 2007 19:36:59 +0200
>> Michael Zedeler <michael@zedeler.dk> wrote:
>>
>>> Ja. Med lidt snilde kan man også skrive et operativsystem, så man
>>> slipper for for den ekstra dødvægt
>>
>> Det er jo ikke altid, der er behov for en full blown webserver.
>> http://www.gnetlibrary.org/
>
> Mnjaeh. Det er bare nemt at komme til at eksponere et program som han
> nogle ubehagelige sikkerhedshuller, webserveren ellers vil fange for en.
> Samtidig er det i mange sammenhænge sværere at vedligeholde og administrere.

Hvilke sikkerhedshuller i et (cgi) program fanger webserveren?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Hvilke sikkerhedshuller i et (cgi) program fanger webserveren?
>

Sikkerhedshuller i implementering af HTTP-protokollen f.eks.

Men jo, CGI er et meget råt interface hvor det er let at lave
alvorlige sikkerhedsbommerter hvis man ikke ved præcis hvad man gør.

Andre C/C++ baserede server side interfaces (ISAPI, Apache moduler etc.)
er lige så risikable at arbejde med som CGI i C. Det er bare lidt
variationer i hvordan ens kode bliver kaldt.

Det samme kan til en vis grad også siges om de fleste server-side
script-systemer (ASP, PHP, JSP, o.s.v.), men disse systemer er i det
mindste baserede på sprog hvor man ikke lige får lavet et bufferoverflow
på en dårlig dag. De fleste øvrige risici er de samme som i C.


--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right.
Information in this posting may not be the official position of Danware
Data A/S, only the personal opinions of the author.

---

Den Sun, 22 Jul 2007 19:51:37 +0200 skrev Jakob Bøhm:
> Kent Friis wrote:
>> Hvilke sikkerhedshuller i et (cgi) program fanger webserveren?
>>
>
> Sikkerhedshuller i implementering af HTTP-protokollen f.eks.

Nu stod der "eksponere et program som har nogle ubehagelige
sikkerhedshuller", det læser jeg som nogen der eksisterer i forvejen,
altså huller i CGI-programmet.

Selvfølgelig betyder yderligere kode yderligere kode der kan være
huller i, men jeg kan ikke se der skulle være større risiko for
at lave en usikker http-implementation end et usikkert CGI-program.

> Men jo, CGI er et meget råt interface hvor det er let at lave
> alvorlige sikkerhedsbommerter hvis man ikke ved præcis hvad man gør.
>
> Andre C/C++ baserede server side interfaces (ISAPI, Apache moduler etc.)
> er lige så risikable at arbejde med som CGI i C. Det er bare lidt
> variationer i hvordan ens kode bliver kaldt.

CGI er et simpelt interface, det vil jeg ikke mene fx et Apache modul
er. Og simpelt interface = færre ting at holde styr på = mindre
risiko for fejl.

> Det samme kan til en vis grad også siges om de fleste server-side
> script-systemer (ASP, PHP, JSP, o.s.v.), men disse systemer er i det
> mindste baserede på sprog hvor man ikke lige får lavet et bufferoverflow
> på en dårlig dag. De fleste øvrige risici er de samme som i C.

Argumentet gik ikke på C vs PHP, men hvorvidt en webserver
beskytter mod fejl i CGI-programmet. Jeg vil godt se den webserver
der kan beskytte mod en buffer overflow i et CGI-program (uden at
ødelægge ikke-defekte programmer, så fx at begrænse POST til 256 tegn
gælder ikke).

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Jeg vil godt se den webserver
> der kan beskytte mod en buffer overflow i et CGI-program (uden at
> ødelægge ikke-defekte programmer, så fx at begrænse POST til 256 tegn
> gælder ikke).

Nu bevæger vi os vist ret langt væk fra det oprindelige emne, men der
findes en firewall, der kan det, du spørger efter. Det er jo logisk set
en helt anden komponent, men man kunne godt have det indbygget som en
slags avanceret filter i sin firewall.

Idéen er at man laver en hvidliste over tilladte HTTP-forespørgsler,
hvorefter kun forespørgsler med de tilladte værdier bliver sluppet igennem.

Problemet er at nogle applikationer kan benytte en type forespørgsler,
der er umulige at checke, så det er ikke nogen universalløsning.

http://www.armorlogic.com/

Mvh. Michael.

---

Den Mon, 23 Jul 2007 02:03:49 +0200 skrev Michael Zedeler:
> Kent Friis wrote:
>> Jeg vil godt se den webserver
>> der kan beskytte mod en buffer overflow i et CGI-program (uden at
>> ødelægge ikke-defekte programmer, så fx at begrænse POST til 256 tegn
>> gælder ikke).
>
> Nu bevæger vi os vist ret langt væk fra det oprindelige emne, men der
> findes en firewall, der kan det, du spørger efter. Det er jo logisk set
> en helt anden komponent, men man kunne godt have det indbygget som en
> slags avanceret filter i sin firewall.
>
> Idéen er at man laver en hvidliste over tilladte HTTP-forespørgsler,
> hvorefter kun forespørgsler med de tilladte værdier bliver sluppet igennem.

Så for buffer-overflows vedkommende betyder det at firewall'en skal
vide størrelsen på hver eneste buffer i hvert eneste CGI-program...

Var det så ikke smartere at skifte gets ud med fgets, når man
alligevel skal checke koden?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Den Mon, 23 Jul 2007 02:03:49 +0200 skrev Michael Zedeler:
>> Kent Friis wrote:
>>> Jeg vil godt se den webserver
>>> der kan beskytte mod en buffer overflow i et CGI-program (uden at
>>> ødelægge ikke-defekte programmer, så fx at begrænse POST til 256 tegn
>>> gælder ikke).
>> Nu bevæger vi os vist ret langt væk fra det oprindelige emne, men der
>> findes en firewall, der kan det, du spørger efter. Det er jo logisk set
>> en helt anden komponent, men man kunne godt have det indbygget som en
>> slags avanceret filter i sin firewall.
>>
>> Idéen er at man laver en hvidliste over tilladte HTTP-forespørgsler,
>> hvorefter kun forespørgsler med de tilladte værdier bliver sluppet igennem.
>
> Så for buffer-overflows vedkommende betyder det at firewall'en skal
> vide størrelsen på hver eneste buffer i hvert eneste CGI-program...

Det er vist ikke meningen. Den firewall jeg har anført et link til
benytter regulære udtryk til at checke om en parameter f. eks. ser ud
til at indeholde en valid email-adresse, en url, et navn og så
fremdeles. Så det er selvfølgelig temmelig omfattende at sætte op, men
skulle da gerne give god beskyttelse imod mærkelige forespørgsler.

> Var det så ikke smartere at skifte gets ud med fgets, når man
> alligevel skal checke koden?

Det forudsætter at man har adgang til koden...

Mvh. Michael.

---

Den Mon, 23 Jul 2007 19:47:15 +0200 skrev Michael Zedeler:
> Kent Friis wrote:
>> Den Mon, 23 Jul 2007 02:03:49 +0200 skrev Michael Zedeler:
>>> Kent Friis wrote:
>>>> Jeg vil godt se den webserver
>>>> der kan beskytte mod en buffer overflow i et CGI-program (uden at
>>>> ødelægge ikke-defekte programmer, så fx at begrænse POST til 256 tegn
>>>> gælder ikke).
>>> Nu bevæger vi os vist ret langt væk fra det oprindelige emne, men der
>>> findes en firewall, der kan det, du spørger efter. Det er jo logisk set
>>> en helt anden komponent, men man kunne godt have det indbygget som en
>>> slags avanceret filter i sin firewall.
>>>
>>> Idéen er at man laver en hvidliste over tilladte HTTP-forespørgsler,
>>> hvorefter kun forespørgsler med de tilladte værdier bliver sluppet igennem.
>>
>> Så for buffer-overflows vedkommende betyder det at firewall'en skal
>> vide størrelsen på hver eneste buffer i hvert eneste CGI-program...
>
> Det er vist ikke meningen. Den firewall jeg har anført et link til
> benytter regulære udtryk til at checke om en parameter f. eks. ser ud
> til at indeholde en valid email-adresse, en url, et navn og så
> fremdeles. Så det er selvfølgelig temmelig omfattende at sætte op, men
> skulle da gerne give god beskyttelse imod mærkelige forespørgsler.

Det hjælper jo ikke mod en buffer overflow.

Spørgsmålet lød: "Jeg vil godt se den webserver der kan beskytte mod en
buffer overflow i et CI-program".

>> Var det så ikke smartere at skifte gets ud med fgets, når man
>> alligevel skal checke koden?
>
> Det forudsætter at man har adgang til koden...

Det gør det også at finde bufferens størrelse.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Den Mon, 23 Jul 2007 19:47:15 +0200 skrev Michael Zedeler:
>> Kent Friis wrote:
>>> Den Mon, 23 Jul 2007 02:03:49 +0200 skrev Michael Zedeler:
>>>> Kent Friis wrote:
>>>>> Jeg vil godt se den webserver
>>>>> der kan beskytte mod en buffer overflow i et CGI-program (uden at
>>>>> ødelægge ikke-defekte programmer, så fx at begrænse POST til 256 tegn
>>>>> gælder ikke).
>>>> Nu bevæger vi os vist ret langt væk fra det oprindelige emne, men der
>>>> findes en firewall, der kan det, du spørger efter. Det er jo logisk set
>>>> en helt anden komponent, men man kunne godt have det indbygget som en
>>>> slags avanceret filter i sin firewall.
>>>>
>>>> Idéen er at man laver en hvidliste over tilladte HTTP-forespørgsler,
>>>> hvorefter kun forespørgsler med de tilladte værdier bliver sluppet igennem.
>>> Så for buffer-overflows vedkommende betyder det at firewall'en skal
>>> vide størrelsen på hver eneste buffer i hvert eneste CGI-program...
>> Det er vist ikke meningen. Den firewall jeg har anført et link til
>> benytter regulære udtryk til at checke om en parameter f. eks. ser ud
>> til at indeholde en valid email-adresse, en url, et navn og så
>> fremdeles. Så det er selvfølgelig temmelig omfattende at sætte op, men
>> skulle da gerne give god beskyttelse imod mærkelige forespørgsler.
>
> Det hjælper jo ikke mod en buffer overflow.
>
> Spørgsmålet lød: "Jeg vil godt se den webserver der kan beskytte mod en
> buffer overflow i et CI-program".

Jeg går ud fra at man også gør sig nogle tanker om længden af de
tilladte felter, når man konfigurerer systemet.

>>> Var det så ikke smartere at skifte gets ud med fgets, når man
>>> alligevel skal checke koden?
>> Det forudsætter at man har adgang til koden...
>
> Det gør det også at finde bufferens størrelse.

Nej

Mvh. Michael.

---

Den Mon, 23 Jul 2007 20:19:10 +0200 skrev Michael Zedeler:
> Kent Friis wrote:
>> Den Mon, 23 Jul 2007 19:47:15 +0200 skrev Michael Zedeler:
>>> Kent Friis wrote:
>>>> Den Mon, 23 Jul 2007 02:03:49 +0200 skrev Michael Zedeler:
>>>>> Kent Friis wrote:
>>>>>> Jeg vil godt se den webserver
>>>>>> der kan beskytte mod en buffer overflow i et CGI-program (uden at
>>>>>> ødelægge ikke-defekte programmer, så fx at begrænse POST til 256 tegn
>>>>>> gælder ikke).
>>>>> Nu bevæger vi os vist ret langt væk fra det oprindelige emne, men der
>>>>> findes en firewall, der kan det, du spørger efter. Det er jo logisk set
>>>>> en helt anden komponent, men man kunne godt have det indbygget som en
>>>>> slags avanceret filter i sin firewall.
>>>>>
>>>>> Idéen er at man laver en hvidliste over tilladte HTTP-forespørgsler,
>>>>> hvorefter kun forespørgsler med de tilladte værdier bliver sluppet igennem.
>>>> Så for buffer-overflows vedkommende betyder det at firewall'en skal
>>>> vide størrelsen på hver eneste buffer i hvert eneste CGI-program...
>>> Det er vist ikke meningen. Den firewall jeg har anført et link til
>>> benytter regulære udtryk til at checke om en parameter f. eks. ser ud
>>> til at indeholde en valid email-adresse, en url, et navn og så
>>> fremdeles. Så det er selvfølgelig temmelig omfattende at sætte op, men
>>> skulle da gerne give god beskyttelse imod mærkelige forespørgsler.
>>
>> Det hjælper jo ikke mod en buffer overflow.
>>
>> Spørgsmålet lød: "Jeg vil godt se den webserver der kan beskytte mod en
>> buffer overflow i et CI-program".
>
> Jeg går ud fra at man også gør sig nogle tanker om længden af de
> tilladte felter, når man konfigurerer systemet.

Det kræver da at man kender størrelsen på bufferen.

Man kan selvfølgelig godt sætte nogle idiotiske begrænsninger på
så som at bynavnet ikke må være mere end 15 tegn, og derved afskære
alle der bor i byere med længere navne, men uden at vide om bufferen
er på 16 eller 256 tegn, bliver det ikke til andet end en idiotisk
begrænsning.

Uden at kende buffer-størrelsen har man kun to muligheder - enten laver
man en idiotisk begrænsning der er mindre end hvad programmet kan
håndtere, eller også er ens begrænsning større. Medmindre man
hedder Fætter Højben, og gætter rigtigt hver gang (men i så fald
er man i den forkerte brance... Lotto-branchen giver bedre
indtægter).

>>>> Var det så ikke smartere at skifte gets ud med fgets, når man
>>>> alligevel skal checke koden?
>>> Det forudsætter at man har adgang til koden...
>>
>> Det gør det også at finde bufferens størrelse.
>
> Nej

Hvordan finder du ud af om der står char city[16] eller
char city[256] den at kigge i koden?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Den Mon, 23 Jul 2007 20:19:10 +0200 skrev Michael Zedeler:
>> Kent Friis wrote:
>>> Den Mon, 23 Jul 2007 19:47:15 +0200 skrev Michael Zedeler:
>>>> Kent Friis wrote:
>>>>> Den Mon, 23 Jul 2007 02:03:49 +0200 skrev Michael Zedeler:
>>>>>> Kent Friis wrote:
>>>>>>> Jeg vil godt se den webserver
>>>>>>> der kan beskytte mod en buffer overflow i et CGI-program (uden at
>>>>>>> ødelægge ikke-defekte programmer, så fx at begrænse POST til 256 tegn
>>>>>>> gælder ikke).
>>>>>> Nu bevæger vi os vist ret langt væk fra det oprindelige emne, men der
>>>>>> findes en firewall, der kan det, du spørger efter. Det er jo logisk set
>>>>>> en helt anden komponent, men man kunne godt have det indbygget som en
>>>>>> slags avanceret filter i sin firewall.
>>>>>>
>>>>>> Idéen er at man laver en hvidliste over tilladte HTTP-forespørgsler,
>>>>>> hvorefter kun forespørgsler med de tilladte værdier bliver sluppet igennem.
>>>>> Så for buffer-overflows vedkommende betyder det at firewall'en skal
>>>>> vide størrelsen på hver eneste buffer i hvert eneste CGI-program...
>>>> Det er vist ikke meningen. Den firewall jeg har anført et link til
>>>> benytter regulære udtryk til at checke om en parameter f. eks. ser ud
>>>> til at indeholde en valid email-adresse, en url, et navn og så
>>>> fremdeles. Så det er selvfølgelig temmelig omfattende at sætte op, men
>>>> skulle da gerne give god beskyttelse imod mærkelige forespørgsler.
>>> Det hjælper jo ikke mod en buffer overflow.
>>>
>>> Spørgsmålet lød: "Jeg vil godt se den webserver der kan beskytte mod en
>>> buffer overflow i et CI-program".
>> Jeg går ud fra at man også gør sig nogle tanker om længden af de
>> tilladte felter, når man konfigurerer systemet.
>
> Det kræver da at man kender størrelsen på bufferen.
>
> Man kan selvfølgelig godt sætte nogle idiotiske begrænsninger på
> så som at bynavnet ikke må være mere end 15 tegn, og derved afskære
> alle der bor i byere med længere navne, men uden at vide om bufferen
> er på 16 eller 256 tegn, bliver det ikke til andet end en idiotisk
> begrænsning.
>
> Uden at kende buffer-størrelsen har man kun to muligheder - enten laver
> man en idiotisk begrænsning der er mindre end hvad programmet kan
> håndtere, eller også er ens begrænsning større. Medmindre man
> hedder Fætter Højben, og gætter rigtigt hver gang (men i så fald
> er man i den forkerte brance... Lotto-branchen giver bedre
> indtægter).

Jeg tror at en almindelig fremgangsmåde er at inferere længderne ved at
lave lidt analyse og måske kigge i bagvedliggende systemer. Du har helt
ret i at det ikke giver et præcist billede, men lur mig om ikke det er
hvad de fleste ender med at gøre alligevel.

>>>>> Var det så ikke smartere at skifte gets ud med fgets, når man
>>>>> alligevel skal checke koden?
>>>> Det forudsætter at man har adgang til koden...
>>> Det gør det også at finde bufferens størrelse.
>> Nej
>
> Hvordan finder du ud af om der står char city[16] eller
> char city[256] den at kigge i koden?

Det er jo svært at sige for alle versioner af c-compilere, men hvis det
har en praktisk betydning for hvordan programmet virker, er det også at
finde et sted i det program, compileren spytter ud. Selvfølgelig er det
ikke en skudsikker metode og den kan nemt blive meget dyr, men sådan er
der jo så meget - at validere HTTP-forespørgsler er jo ikke en
universalløsning i første omgang alligevel.

Min pointe er at det i praksis ofte kan være en langt større opgave at
løse sikkerhedsproblemer ved kilden, frem for at sætte
HTTP-filtrerings-firewall imellem det defekte system og resten af
nettet. Det vil til en hver tid være en mindre ideel løsning, men ikke
desto mindre tror jeg at mange vil ende med at bruge den.

Mvh. Michael.

---

Den Mon, 23 Jul 2007 22:12:11 +0200 skrev Michael Zedeler:
> Kent Friis wrote:
>>
>> Uden at kende buffer-størrelsen har man kun to muligheder - enten laver
>> man en idiotisk begrænsning der er mindre end hvad programmet kan
>> håndtere, eller også er ens begrænsning større. Medmindre man
>> hedder Fætter Højben, og gætter rigtigt hver gang (men i så fald
>> er man i den forkerte brance... Lotto-branchen giver bedre
>> indtægter).
>
> Jeg tror at en almindelig fremgangsmåde er at inferere længderne ved at
> lave lidt analyse og måske kigge i bagvedliggende systemer.

Det kan højst blive et kvalificeret gæt.

> Du har helt
> ret i at det ikke giver et præcist billede, men lur mig om ikke det er
> hvad de fleste ender med at gøre alligevel.

"Sikkerhed" på grundlag a gætteri...

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Den Mon, 23 Jul 2007 22:12:11 +0200 skrev Michael Zedeler:
>> Kent Friis wrote:
>>> Uden at kende buffer-størrelsen har man kun to muligheder - enten laver
>>> man en idiotisk begrænsning der er mindre end hvad programmet kan
>>> håndtere, eller også er ens begrænsning større. Medmindre man
>>> hedder Fætter Højben, og gætter rigtigt hver gang (men i så fald
>>> er man i den forkerte brance... Lotto-branchen giver bedre
>>> indtægter).
>> Jeg tror at en almindelig fremgangsmåde er at inferere længderne ved at
>> lave lidt analyse og måske kigge i bagvedliggende systemer.
>
> Det kan højst blive et kvalificeret gæt.

ja. Det er en kort og præcis beskrivelse.

>> Du har helt
>> ret i at det ikke giver et præcist billede, men lur mig om ikke det er
>> hvad de fleste ender med at gøre alligevel.
>
> "Sikkerhed" på grundlag a gætteri...

I mange situationer er det et spørgsmål om at vælge imellem et større og
et mindre onde.

Mvh. Michael.

---

>>>>> Var det så ikke smartere at skifte gets ud med fgets, når man
>>>>> alligevel skal checke koden?
>>>> Det forudsætter at man har adgang til koden...
>>>
>>> Det gør det også at finde bufferens størrelse.
>>
>> Nej
>
> Hvordan finder du ud af om der står char city[16] eller
> char city[256] den at kigge i koden?

Det er da ret let. Debug/disassembler.

---

Den Tue, 24 Jul 2007 14:46:05 +0200 skrev Ivar Bovin:
>>>>>> Var det så ikke smartere at skifte gets ud med fgets, når man
>>>>>> alligevel skal checke koden?
>>>>> Det forudsætter at man har adgang til koden...
>>>>
>>>> Det gør det også at finde bufferens størrelse.
>>>
>>> Nej
>>
>> Hvordan finder du ud af om der står char city[16] eller
>> char city[256] den at kigge i koden?
>
> Det er da ret let. Debug/disassembler.

Hvordan ser assembler-koden for et char-array ud?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Den Sun, 22 Jul 2007 17:14:12 +0200 skrev Michael Zedeler:
>> Michael Rasmussen wrote:
>>> On Thu, 19 Jul 2007 19:36:59 +0200
>>> Michael Zedeler <michael@zedeler.dk> wrote:
>>>
>>>> Ja. Med lidt snilde kan man også skrive et operativsystem, så man
>>>> slipper for for den ekstra dødvægt
>>> Det er jo ikke altid, der er behov for en full blown webserver.
>>> http://www.gnetlibrary.org/
>> Mnjaeh. Det er bare nemt at komme til at eksponere et program som han
>> nogle ubehagelige sikkerhedshuller, webserveren ellers vil fange for en.
>> Samtidig er det i mange sammenhænge sværere at vedligeholde og administrere.
>
> Hvilke sikkerhedshuller i et (cgi) program fanger webserveren?

Den kan jo potentielt fange alt hvad der er out of band ift. HTTP,
hvilket man ifølge sagens natur selv skal gardere sig imod hvis man
skriver sin egen server.

Men eller skriver du jo også selv i et andet indlæg i denne tråd at...

> CGI er et simpelt interface, det vil jeg ikke mene fx et Apache modul
> er. Og simpelt interface = færre ting at holde styr på = mindre
> risiko for fejl.

Det er så mit andet argument - det er mindre komplekst at skrive et
CGI-program sammenlignet med en webserver. Det i sig selv giver bedre
mulighed for at undgå sikkerhedsproblemer, men betyder jo også for
spørgeren at han har nemmere ved at komme i mål med sit projekt.

Mvh. Michael.

---

Den Sun, 22 Jul 2007 21:31:31 +0200 skrev Michael Zedeler:
> Kent Friis wrote:
>> Den Sun, 22 Jul 2007 17:14:12 +0200 skrev Michael Zedeler:
>>> Michael Rasmussen wrote:
>>>> On Thu, 19 Jul 2007 19:36:59 +0200
>>>> Michael Zedeler <michael@zedeler.dk> wrote:
>>>>
>>>>> Ja. Med lidt snilde kan man også skrive et operativsystem, så man
>>>>> slipper for for den ekstra dødvægt
>>>> Det er jo ikke altid, der er behov for en full blown webserver.
>>>> http://www.gnetlibrary.org/
>>> Mnjaeh. Det er bare nemt at komme til at eksponere et program som han
>>> nogle ubehagelige sikkerhedshuller, webserveren ellers vil fange for en.
>>> Samtidig er det i mange sammenhænge sværere at vedligeholde og administrere.
>>
>> Hvilke sikkerhedshuller i et (cgi) program fanger webserveren?
>
> Den kan jo potentielt fange alt hvad der er out of band ift. HTTP,
> hvilket man ifølge sagens natur selv skal gardere sig imod hvis man
> skriver sin egen server.

Det er så ikke huller i cgi-programmet, men i webserveren (Uanset at
de så er samlet i samme executable).

Jeg er ikke uenig i at det ofte vil være overkill at begynde at skrive
sin egen webserver, og mindre kode = mindre risiko for fejl, men
formuleringen fik det til at lyde som om at webserveren beskytter
mod fejl i CGI-programmet - i modsætning til fejl i webserver-delen.

Noget helt andet er så at en simpel webserver på måske 100 linier
har meget færre muligheder for fejl end fx Apache på hvor mange
tusind linier. Men det kommer selvfølgelig an på hvor dygtig
programmøren er, og hvor meget tid der er brugt på test.

Men nu er Apache så også overkill i mange tilfælde, thttpd eller
lighttpd ville nok give fordelene fra begge sider - meget færre linier
(sammenlignet med Apache) og gennemprøvet kode skrevet af folk der
ved hvad de har med at gøre.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Det er så ikke huller i cgi-programmet, men i webserveren (Uanset at
> de så er samlet i samme executable).

Lige netop CGI scripts er jo ikke i samme executable ...

Arne

---

Kent Friis wrote:
> Den Sun, 22 Jul 2007 21:31:31 +0200 skrev Michael Zedeler:
>> Kent Friis wrote:
>>> Den Sun, 22 Jul 2007 17:14:12 +0200 skrev Michael Zedeler:
>>>> Michael Rasmussen wrote:
>>>>> On Thu, 19 Jul 2007 19:36:59 +0200
>>>>> Michael Zedeler <michael@zedeler.dk> wrote:
>>>>>
>>>>>> Ja. Med lidt snilde kan man også skrive et operativsystem, så man
>>>>>> slipper for for den ekstra dødvægt
>>>>> Det er jo ikke altid, der er behov for en full blown webserver.
>>>>> http://www.gnetlibrary.org/
>>>> Mnjaeh. Det er bare nemt at komme til at eksponere et program som han
>>>> nogle ubehagelige sikkerhedshuller, webserveren ellers vil fange for en.
>>>> Samtidig er det i mange sammenhænge sværere at vedligeholde og administrere.
>>> Hvilke sikkerhedshuller i et (cgi) program fanger webserveren?
>> Den kan jo potentielt fange alt hvad der er out of band ift. HTTP,
>> hvilket man ifølge sagens natur selv skal gardere sig imod hvis man
>> skriver sin egen server.
>
> Det er så ikke huller i cgi-programmet, men i webserveren (Uanset at
> de så er samlet i samme executable).
>
> Jeg er ikke uenig i at det ofte vil være overkill at begynde at skrive
> sin egen webserver, og mindre kode = mindre risiko for fejl, men
> formuleringen fik det til at lyde som om at webserveren beskytter
> mod fejl i CGI-programmet - i modsætning til fejl i webserver-delen.

Da jeg skrev "komme til at eksponere et program som ha[r] nogle
ubehagelige sikkerhedshuller", mente jeg at man ved at skrive en
webserver skal holde styr på flere potentielle problemer, som man så
ender med at eksponere på Internettet.

> Noget helt andet er så at en simpel webserver på måske 100 linier
> har meget færre muligheder for fejl end fx Apache på hvor mange
> tusind linier. Men det kommer selvfølgelig an på hvor dygtig
> programmøren er, og hvor meget tid der er brugt på test.

Ja. Jeg er enig i at sådan et avanceret stykke software som Apache er et
tveægget sværd. På den ene side har man en udfordring i at skrive en
minimal, men sikker webserver - på den anden side er der at konfigurere
Apache korrekt og vedligeholde den.

Men i denne sammenhæng hvor der er spurgt efter "den almindelige måde"
at skrive et program der kan generere dynamiske websider, er det imho
det klart mest oplagte at anbefale CGI. Hvis man bliver træt af
webserveren, kan man jo altid smide den væk og skrive en selv - det
kommer ikke til at tage meget ekstra tid ift. at skrive webserveren fra
starten.

> Men nu er Apache så også overkill i mange tilfælde, thttpd eller
> lighttpd ville nok give fordelene fra begge sider - meget færre linier
> (sammenlignet med Apache) og gennemprøvet kode skrevet af folk der
> ved hvad de har med at gøre.

Ja. I mit oprindelige indlæg skrev jeg skam også med fuldt overlæg IKKE
"Apache", men blot "webserver".

Mvh. Michael.