mboost-dp1
SXC - clix
#47: Jeg vil give dig ret i at tid plus brugernavn er nemt at bryde, men det kan stadig godt være nogenlunde sikkert, hvis nøglen også indeholder passwordet. Så bliver brugernavnet bare irrelevant. Problemet begynder dog at vise sig, hvis nøglen har kendte kollisioner. Hvis tiden er med, giver den jo muligvis en ide om opbygningen af en del af plainteksten. Om ikke andet, så ihvertfald alfabetet for de tegn, som den del af nøglen indeholder.
#47.
Ikke hvis denne ændre sig hvergang bruger loger ind.
Her taler vi ikke om at lager noget data på selve brugerens harddisk men i hukommelsen.
#46
Ikke hvis du får fat i systemet, bruger det og scanner hukommelsen som det bruger der ved, har du en ide om hvordan det adressere igennem forløbet.
På baggrund af dette info kan du bygge en orm som så henter dette data ud og sender det til dig og så har du adgang til firmaets database.
Eks.
Download den applikation som et lille fly selvskab bruger til at lave reservationer og booking.(Og jeg taler ikke om problematiken om at få fat i dette software)
Brug dette software mens du har en hook der scanner hukommelsen i det område hvor programmet allokere, og find disse områder der håndtere SQL login og processer.
find ud af hvor den starter den føste SQL Transaktion dette vil givet være der hvor man loger ind på SQL databasen.
Undersøg dette data område nærmere og find ud af hvilke områder der bliver adresseret variabler og ligende.
hent det data der står her har du ca 20 - 30 % Chanse for at data ikke er krypteret.
at dette ikke bare er noget du lige sætter dig ned og gør på 5 min med en lille VB book for beginner ja det er næsten givet, men dette er kendt som et program hack og har en sværheds grad på Advanced - Very Advanced, men det er måden du gør det på.
Ikke hvis denne ændre sig hvergang bruger loger ind.
Her taler vi ikke om at lager noget data på selve brugerens harddisk men i hukommelsen.
#46
Ikke hvis du får fat i systemet, bruger det og scanner hukommelsen som det bruger der ved, har du en ide om hvordan det adressere igennem forløbet.
På baggrund af dette info kan du bygge en orm som så henter dette data ud og sender det til dig og så har du adgang til firmaets database.
Eks.
Download den applikation som et lille fly selvskab bruger til at lave reservationer og booking.(Og jeg taler ikke om problematiken om at få fat i dette software)
Brug dette software mens du har en hook der scanner hukommelsen i det område hvor programmet allokere, og find disse områder der håndtere SQL login og processer.
find ud af hvor den starter den føste SQL Transaktion dette vil givet være der hvor man loger ind på SQL databasen.
Undersøg dette data område nærmere og find ud af hvilke områder der bliver adresseret variabler og ligende.
hent det data der står her har du ca 20 - 30 % Chanse for at data ikke er krypteret.
at dette ikke bare er noget du lige sætter dig ned og gør på 5 min med en lille VB book for beginner ja det er næsten givet, men dette er kendt som et program hack og har en sværheds grad på Advanced - Very Advanced, men det er måden du gør det på.
Et godt eksempel kunne være DBS for nogle år tilbage havde et kald til en .exe direkte på deres webside.
Dvs. man kunne se .exe i url'en. Og mon ikke man kunne finde en måde at downloade den på.
Eller netbankernes Java Applets til login. Tænk hvis de havde hardcoded passwords *gys* (Java er ret nemt at decompile.)
Dvs. man kunne se .exe i url'en. Og mon ikke man kunne finde en måde at downloade den på.
Eller netbankernes Java Applets til login. Tænk hvis de havde hardcoded passwords *gys* (Java er ret nemt at decompile.)
#54
Nu DSB og IT ikke to ting jeg ønsker at sætte på samme linie selv om jeg gør det i dette indlæg bare dette får det til at gyse.
Jeg har tit set Crash på DSB's info system hvor man får interesante fejl beskeder som giver alt alt for meget info, og det er på info skærmene ikke noget man har lyst til at populere ud til 100.000 kunder som tager DSB hverdag.
men det har DSB åben bart lyst til fred være med det
Hvis jeg havde været DSB ville jeg have skrevet det lokalt og så når programmet havde kunne se Databasen sende dette som en log entry, og ikke bare smække det op på storskærmen.
Nu DSB og IT ikke to ting jeg ønsker at sætte på samme linie selv om jeg gør det i dette indlæg bare dette får det til at gyse.
Jeg har tit set Crash på DSB's info system hvor man får interesante fejl beskeder som giver alt alt for meget info, og det er på info skærmene ikke noget man har lyst til at populere ud til 100.000 kunder som tager DSB hverdag.
men det har DSB åben bart lyst til fred være med det
Hvis jeg havde været DSB ville jeg have skrevet det lokalt og så når programmet havde kunne se Databasen sende dette som en log entry, og ikke bare smække det op på storskærmen.
#53
Nej. Men den er jo så tilgengæld ubrugelig til de allerfleste formål. Keys til symmetrisk kryptering skal jo netop kendes af både encrypter og decrypter for at kunne bruges.
Ikke hvis denne ændre sig hvergang bruger loger ind.
Her taler vi ikke om at lager noget data på selve brugerens harddisk men i hukommelsen.
Nej. Men den er jo så tilgengæld ubrugelig til de allerfleste formål. Keys til symmetrisk kryptering skal jo netop kendes af både encrypter og decrypter for at kunne bruges.
#53
Jeg gentager: det kræver privs hvis du skal læse en anden processes address space. Hvis man har privs er alt muligt. Det er ikke en sikkerhedsrisiko men en selvfølge.
Og det er overhovedet ikke avanceret at slå op i MSDN at det kræver privs.
http://msdn.microsoft.com/en-us/library/ms680553.a...
siger:
The handle must have PROCESS_VM_READ access to the process.
http://msdn.microsoft.com/en-us/library/ms684320.a...
siger:
This access right is checked against the security descriptor for the process.
Ikke hvis du får fat i systemet, bruger det og scanner hukommelsen som det bruger der ved, har du en ide om hvordan det adressere igennem forløbet.
På baggrund af dette info kan du bygge en orm som så henter dette data ud og sender det til dig og så har du adgang til firmaets database.
Eks.
Download den applikation som et lille fly selvskab bruger til at lave reservationer og booking.(Og jeg taler ikke om problematiken om at få fat i dette software)
Brug dette software mens du har en hook der scanner hukommelsen i det område hvor programmet allokere, og find disse områder der håndtere SQL login og processer.
find ud af hvor den starter den føste SQL Transaktion dette vil givet være der hvor man loger ind på SQL databasen.
Undersøg dette data område nærmere og find ud af hvilke områder der bliver adresseret variabler og ligende.
hent det data der står her har du ca 20 - 30 % Chanse for at data ikke er krypteret.
at dette ikke bare er noget du lige sætter dig ned og gør på 5 min med en lille VB book for beginner ja det er næsten givet, men dette er kendt som et program hack og har en sværheds grad på Advanced - Very Advanced, men det er måden du gør det på.
Jeg gentager: det kræver privs hvis du skal læse en anden processes address space. Hvis man har privs er alt muligt. Det er ikke en sikkerhedsrisiko men en selvfølge.
Og det er overhovedet ikke avanceret at slå op i MSDN at det kræver privs.
http://msdn.microsoft.com/en-us/library/ms680553.a...
siger:
The handle must have PROCESS_VM_READ access to the process.
http://msdn.microsoft.com/en-us/library/ms684320.a...
siger:
This access right is checked against the security descriptor for the process.
#56
Hmmm, I Active Directory bruges der selvfølgelig kerberos eller NTLM, når du siger Windows Authentication, er det så det du hentyder til?
Det er rigtigt at NTLM er token baseret når du transmitterer dataen, men derudover bruger du stadig passwordet som input data til dine requests, eller rettere en MD5 hash af dit password. NTLM tilføjer idag reelt kun ekstra sikkerhed i den transmitterede data, ikke i hvilket data der skal bruges til din request, det skjuler dit password bag en svag MD5 hash, som kan brydes med rainbow tables.
Det samme gælder kerberos, til database authentication brug med kerberos vil du typsik bruge en keytab, og hvis du som cracker kan komme i nærheden af den keytab har du samme situation, bortset fra at du med keytaben abstraherer fra passwordet.
Kerberos og NTLM beskytter data på netværket, ikke på maskinen i nogen af enderne.
Hmmm, I Active Directory bruges der selvfølgelig kerberos eller NTLM, når du siger Windows Authentication, er det så det du hentyder til?
Det er rigtigt at NTLM er token baseret når du transmitterer dataen, men derudover bruger du stadig passwordet som input data til dine requests, eller rettere en MD5 hash af dit password. NTLM tilføjer idag reelt kun ekstra sikkerhed i den transmitterede data, ikke i hvilket data der skal bruges til din request, det skjuler dit password bag en svag MD5 hash, som kan brydes med rainbow tables.
Det samme gælder kerberos, til database authentication brug med kerberos vil du typsik bruge en keytab, og hvis du som cracker kan komme i nærheden af den keytab har du samme situation, bortset fra at du med keytaben abstraherer fra passwordet.
Kerberos og NTLM beskytter data på netværket, ikke på maskinen i nogen af enderne.
#54
Nu er cgi altså stadig ret brugt, og det er jo ligepræcist eksekverbare filer direkte i stien, jeg kan helt ærligt ikke se hvad forskellen er på at ekserkvere ekserkverbart kode og et skript.
For at være helt ærligt er det den latterligste kommentar til sikkerhed på en webserver jeg har hørt længe, cgi er super hurtigt hvis du sætter det op rigtigt, og hvis du kan hente cgi filen (.exe, .cgi, whatever) så kan du altså også gøre det samme for ethvert andet skriptsprog. CGI er ikke en bønne mere usikkert end .net, php eller nogen af de andre, du får stadig ikke andet end outputtet af det der bliver ekserkveret returneret.
#62
Men ligegyldigt hvad, er det vel stadig NTLMv2 protokollen eller Kerberos 5 det dækker over, ikke?
Og en NTLMv2 challenge bliver genereret udfra en response-challenge fra serveren og requesterens MD5-hash.
Og nu er jeg ret sikker på at der er MD5 rainbowtables der tager alt op til 8 karakterer.
Nu er cgi altså stadig ret brugt, og det er jo ligepræcist eksekverbare filer direkte i stien, jeg kan helt ærligt ikke se hvad forskellen er på at ekserkvere ekserkverbart kode og et skript.
For at være helt ærligt er det den latterligste kommentar til sikkerhed på en webserver jeg har hørt længe, cgi er super hurtigt hvis du sætter det op rigtigt, og hvis du kan hente cgi filen (.exe, .cgi, whatever) så kan du altså også gøre det samme for ethvert andet skriptsprog. CGI er ikke en bønne mere usikkert end .net, php eller nogen af de andre, du får stadig ikke andet end outputtet af det der bliver ekserkveret returneret.
#62
Men ligegyldigt hvad, er det vel stadig NTLMv2 protokollen eller Kerberos 5 det dækker over, ikke?
Og en NTLMv2 challenge bliver genereret udfra en response-challenge fra serveren og requesterens MD5-hash.
Og nu er jeg ret sikker på at der er MD5 rainbowtables der tager alt op til 8 karakterer.
#63
Muligvis, men det betragtes også som mere sikkert ikke at lade sit website give informationer om hvad der er udviklet i, og på hvilken HTTPd det kører på.
Desværre er det meget svært at sløre. Dog vil jeg mene at direkte CGI ved en .exe fil virker et mere oplagt mål end en tilfældig .php fil hvor du ikke har en ide om det har adgang til noget vigtigt eller ej, hvorimod at du med CGI næsten er sikker på at det er noget som kører opslag eller tunge kodedele.
Intet med sikkerhed er latterligt. Det handler mere om at vuderer hvor vigtige de informationer man beskytter er.
En faktura der viser at hr. hansen er købt en spade er mindre vigtig at sikre end de konto/kort -informationer han brugte til betalingen.
Muligvis, men det betragtes også som mere sikkert ikke at lade sit website give informationer om hvad der er udviklet i, og på hvilken HTTPd det kører på.
Desværre er det meget svært at sløre. Dog vil jeg mene at direkte CGI ved en .exe fil virker et mere oplagt mål end en tilfældig .php fil hvor du ikke har en ide om det har adgang til noget vigtigt eller ej, hvorimod at du med CGI næsten er sikker på at det er noget som kører opslag eller tunge kodedele.
Intet med sikkerhed er latterligt. Det handler mere om at vuderer hvor vigtige de informationer man beskytter er.
En faktura der viser at hr. hansen er købt en spade er mindre vigtig at sikre end de konto/kort -informationer han brugte til betalingen.
Nej, klart nok. Men jeg vil ikke mene at det er obscurity at undlade at vise informationer.
Det er et tillæg til de andre sikkerhedsforansaltninger du foretager dig.
Hvis tyven ved at der er overvågning, er der størrere chance for at han ikke bryder ind, og visa versa.
Men det bør altid være et sidste finish, og ikke noget man baserer resten af sin sikkerhed på.
Det er et tillæg til de andre sikkerhedsforansaltninger du foretager dig.
Hvis tyven ved at der er overvågning, er der størrere chance for at han ikke bryder ind, og visa versa.
Men det bør altid være et sidste finish, og ikke noget man baserer resten af sin sikkerhed på.
F.eks. hvis jeg skal give et eksempel på SQL injection.
Jeg ser at siden er noget i klassisk asp (.asp). Jeg ved at mange asp programmører ikke har en klaphat forstand på prepared statements, og at mulighederne for type validering er umidbart dårligerer end i php.
Derfor er muligheden for en SQL injection rimelig.
Og så til testen. Siden det er ASP kan vi næsten gå ud fra at det er MS SQL (medium størrelse side). Så en god måde at teste rettigheder på, uden at ødelægge data (best til "friendly" tests), er at kører en shutdown.
Derfor kører jeg så følgende SQL:
'; shutdown();
Og griner af siden som herefter ... dør ret meget ud :)
At vide hvilken type database der kører synes at være ret effiktivt.
Herefter kunne man så tænke at DB brugeren nok er default "sa", og at databasen er kørt som administrator på serveren.
Dvs. gennem SQL Server's mulighed for at eksekverer batch kommandoer har vi nu administrator adgang til hele serveren.
Skræmmende - og et virkelig eksempel.
Jeg ser at siden er noget i klassisk asp (.asp). Jeg ved at mange asp programmører ikke har en klaphat forstand på prepared statements, og at mulighederne for type validering er umidbart dårligerer end i php.
Derfor er muligheden for en SQL injection rimelig.
Og så til testen. Siden det er ASP kan vi næsten gå ud fra at det er MS SQL (medium størrelse side). Så en god måde at teste rettigheder på, uden at ødelægge data (best til "friendly" tests), er at kører en shutdown.
Derfor kører jeg så følgende SQL:
'; shutdown();
Og griner af siden som herefter ... dør ret meget ud :)
At vide hvilken type database der kører synes at være ret effiktivt.
Herefter kunne man så tænke at DB brugeren nok er default "sa", og at databasen er kørt som administrator på serveren.
Dvs. gennem SQL Server's mulighed for at eksekverer batch kommandoer har vi nu administrator adgang til hele serveren.
Skræmmende - og et virkelig eksempel.
#64 #69
Jeg vil påstå at når vi er nede at at diskutere hvorvidt .php eller .exe angiver vigtigheden af en process, så er vi ude i noget abstrakt. Og derudover vil du med stor sandsynlighed have adgang til hele webroden hvis du har adgang til at trække source dataen.
Hvis vi tager hvad jeg vil kalde et rimeligt eksempel, hvor du har to ens programmer, et lavet i CGI, et i .Net, og du har fuld adgang til webroden, så vil jeg mene sikkerhedsbrudet er lige stort.
Men jo, jeg ville nok også bruge mod_rewrite og efternavnsløse cgi skripts hvis jeg kørte cgi, men det er nu ligesåmeget for det estetiske. Det ville jeg iøvrigt også overveje med php osv. Jeg ser generelt ingen grund til at bruge efternavne overhovedet, men det er så bare mig.
#66
Det er kun hvis du koder dit CGI så der skal spawnes en thread per request, hvis du bruger mod_fastcgi eller mod_perl er der ingen forskel af betydning.
#67
Med alt respekt, NTLM er en netværksprotokol, dens opgave er at sikre netværkstransmission, hvis du læser dig frem til at du ikke kan bruge MD5 til at bryde den hash der transmitteres har du ret, men du SKAL bruge en MD5-hash af passwordet for at generere den, og så er vi jo lidt tilbage til udgangspunktet. Din kode skal bruge adgang til en MD5 hash af passwordet, som den i tilfælde af Windows authentication får fra Windows SAM databasen.
Hvis du kører Active Directory bruger du kerberos som bruger en keytab, igen et stykke lokalt data som web applikationen skal bruge.
Windows authentication ændrer ikke på at hvis en cracker kan bryde ind i din webrod, eller finde fejl i din kode kan han få fat i information der gør ham i stand til at generere de samme requests som du gør.
NTLM er næsten værdiløst, kerberos er lækkert, men i den her sammenhæng er de begge værdiløse. De er begge lavet til at sikre dataen på netværket, ikke lokalt!
#70
:)
Jeg vil påstå at når vi er nede at at diskutere hvorvidt .php eller .exe angiver vigtigheden af en process, så er vi ude i noget abstrakt. Og derudover vil du med stor sandsynlighed have adgang til hele webroden hvis du har adgang til at trække source dataen.
Hvis vi tager hvad jeg vil kalde et rimeligt eksempel, hvor du har to ens programmer, et lavet i CGI, et i .Net, og du har fuld adgang til webroden, så vil jeg mene sikkerhedsbrudet er lige stort.
Men jo, jeg ville nok også bruge mod_rewrite og efternavnsløse cgi skripts hvis jeg kørte cgi, men det er nu ligesåmeget for det estetiske. Det ville jeg iøvrigt også overveje med php osv. Jeg ser generelt ingen grund til at bruge efternavne overhovedet, men det er så bare mig.
#66
Det er kun hvis du koder dit CGI så der skal spawnes en thread per request, hvis du bruger mod_fastcgi eller mod_perl er der ingen forskel af betydning.
#67
Med alt respekt, NTLM er en netværksprotokol, dens opgave er at sikre netværkstransmission, hvis du læser dig frem til at du ikke kan bruge MD5 til at bryde den hash der transmitteres har du ret, men du SKAL bruge en MD5-hash af passwordet for at generere den, og så er vi jo lidt tilbage til udgangspunktet. Din kode skal bruge adgang til en MD5 hash af passwordet, som den i tilfælde af Windows authentication får fra Windows SAM databasen.
Hvis du kører Active Directory bruger du kerberos som bruger en keytab, igen et stykke lokalt data som web applikationen skal bruge.
Windows authentication ændrer ikke på at hvis en cracker kan bryde ind i din webrod, eller finde fejl i din kode kan han få fat i information der gør ham i stand til at generere de samme requests som du gør.
NTLM er næsten værdiløst, kerberos er lækkert, men i den her sammenhæng er de begge værdiløse. De er begge lavet til at sikre dataen på netværket, ikke lokalt!
#70
:)
#71
Nej hvis man ikke bruger CGI så er CGI ikke et problem. Men øhm.
(mod_ er et Apache module som er en erstatning for CGI)
Det er kun hvis du koder dit CGI så der skal spawnes en thread per request, hvis du bruger mod_fastcgi eller mod_perl er der ingen forskel af betydning.
Nej hvis man ikke bruger CGI så er CGI ikke et problem. Men øhm.
(mod_ er et Apache module som er en erstatning for CGI)
Windcape (70) skrev:Jeg ser at siden er noget i klassisk asp (.asp). Jeg ved at mange asp programmører ikke har en klaphat forstand på prepared statements,
Og det er et eksempel på at det er skidt, at have ".asp" i urlerne? Jeg synes da jeg kan se et noget større problem, som er ret meget mere væsentligt at gøre noget ved.
Windcape (70) skrev:Så en god måde at teste rettigheder på, uden at ødelægge data (best til "friendly" tests), er at kører en shutdown.
Derfor kører jeg så følgende SQL:
'; shutdown();
Hvis det er "friendly", så vil jeg da nødig være din ven.
Du kunne jo blot have gjort dette:
'
Så ville du se en fejl, uden at ødelægge noget. Det ville godt nok ikke bekræfte at du har administrator-adgang, men alligevel.
(Så vil nogle jo argumentere for at det er godt for dem, at du lukker deres usikre server ned.)
I øvrigt kunne samme angreb sagtens kunne ske uden ".asp" i urlen.
Da jeg havde min egen webserver kunne jeg se loggen smæk-fyldt med IIS-specifikke angreb, selv om der intet Microsoft-relateret var på maskinen. Suk.
#73
Helt indrømmet, men en hash af en brudt krypteringsalgoritme er ikke meget bedre end at det bare er passwordet.
Jeg vil påstå at de to sikkerhedsmæssigt er ækvivalente i praksis. Du har stadig det essentielt samme problem at du skal have adgang til noget der har en direkte relation til dit password og som let kan brydes.
Og okay, så kan du muligvis få noget ud af at lave en 40 tegns password, som muligvis bliver svært at bryde.
#72
Ehm, mod_cgi er et apache modul der spawner en thread hver gang du kører det, og det er den klassiske måde at køre CGI på apache. Hvordan det virker på IIS ved jeg ikke meget om.
mod_fastcgi tillader dig at kode CGI kode som returnerer data uden at afslutte, og derfor ikke skal lave en setup hver gang.
mod_perl er også et CGI modul, med optimationer.
Alle tre kan køre CGI uden modifikationer, prøv selv.
Helt indrømmet, men en hash af en brudt krypteringsalgoritme er ikke meget bedre end at det bare er passwordet.
Jeg vil påstå at de to sikkerhedsmæssigt er ækvivalente i praksis. Du har stadig det essentielt samme problem at du skal have adgang til noget der har en direkte relation til dit password og som let kan brydes.
Og okay, så kan du muligvis få noget ud af at lave en 40 tegns password, som muligvis bliver svært at bryde.
#72
Ehm, mod_cgi er et apache modul der spawner en thread hver gang du kører det, og det er den klassiske måde at køre CGI på apache. Hvordan det virker på IIS ved jeg ikke meget om.
mod_fastcgi tillader dig at kode CGI kode som returnerer data uden at afslutte, og derfor ikke skal lave en setup hver gang.
mod_perl er også et CGI modul, med optimationer.
Alle tre kan køre CGI uden modifikationer, prøv selv.
Overbevisende demonstrationer fungerer bedst.myplacedk (74) skrev:Så ville du se en fejl, uden at ødelægge noget. Det ville godt nok ikke bekræfte at du har administrator-adgang, men alligevel.
Det er lidt ligesom at reklamerne for at tage sikkerhedselen på er nået op på et sandt gyser film niveau ;-)
Det er noget i stil med dette her der gør jeg synes man bør undgå at gør det alt for synligt hvilket system man kører.myplacedk (74) skrev:Da jeg havde min egen webserver kunne jeg se loggen smæk-fyldt med IIS-specifikke angreb, selv om der intet Microsoft-relateret var på maskinen. Suk.
Ikke at der allerede BURDE være taget hånd om disse ting, men det er man desværre ikke altid herre over selv.
SQL Server er mig bekendt den eneste database som tillader du slukker for den via. inline SQL.myplacedk (74) skrev:I øvrigt kunne samme angreb sagtens kunne ske uden ".asp" i urlen.
Og jeg synes bestemt ikke det er smart at det overhovedet er muligt.
ASP bruger næsten altid SQL Server, og hvis ikke, kan man jo begynde at lede efter typiske filnavne for access databasen så faktisk en del gange lægger i public root.
Windcape (76) skrev:Overbevisende demonstrationer fungerer bedst.
Ja. Men du kaldte det ikke en "overbevisende demonstration", du kaldte det en "friendly test". ;-)
Windcape (76) skrev:SQL Server er mig bekendt den eneste database som tillader du slukker for den via. inline SQL.
Jeg tror at enhver SQL server tillader "farligt" SQL, hvis man har tilstrækkelige rettigheder.
Og jeg kender flere andre end SQL Server med mulighed for shutdown via SQL.
Man kan lave mange farlige ting med SQL, uden overhovedet at ane hvilken server det er, og hvilket sprog "hullet" er kodet i.
SmackedFly (75) skrev:#73
Helt indrømmet, men en hash af en brudt krypteringsalgoritme er ikke meget bedre end at det bare er passwordet.
Jeg vil påstå at de to sikkerhedsmæssigt er ækvivalente i praksis. Du har stadig det essentielt samme problem at du skal have adgang til noget der har en direkte relation til dit password og som let kan brydes.
Og okay, så kan du muligvis få noget ud af at lave en 40 tegns password, som muligvis bliver svært at bryde.
Det kan vi jo diskutere længe.
Men lad os lave et eksperiment.
2 scenarier:
A)
SqlConnection(@"Server=arnepc3,1639;Database=Test;User Id=sa;Password=hemmeligt");
B)
new SqlConnection("Server=ARNEPC3;Integrated Security=SSPI;Database=Test")
og MD5 af password er:
1d17776da14d5588e1ab9a806109698c
så ser hvor hurtigt folk kan finde password for A og B.
SmackedFly (75) skrev:
mod_perl er også et CGI modul, med optimationer.
mod_perl bruger ikke CGI men en langt mere effektiv model.
SmackedFly (75) skrev:
Alle tre kan køre CGI uden modifikationer, prøv selv.
Det var dog det mest tåbelige jeg længe har hørt.
Kan mod_perl køre et CGI script som er en executable bygget fra C ?
Nej - jeg gider ikke engang prøve.
Det er selvindlysende, at det kan ikke lade sig gøre.
mod_perl kan muligvis køre Perl CGI script uændret.
#79
Processer og tråde er ækvivalente på Unix.
#80
JA!
Det mindste du kunne gøre var lige at gå ind og kigge på mod_perls forside inden du sviner mig til.
mod_perl bruger CGI til at køre interpreteren, men du kan fint bede den om at køre alle mulige andre scripts, i alle mulige andre sprog. Det kunne være du skulle begynde at læse mere end navnet når du vurderer hvad software gør!
Processer og tråde er ækvivalente på Unix.
#80
JA!
Det mindste du kunne gøre var lige at gå ind og kigge på mod_perls forside inden du sviner mig til.
mod_perl is more than CGI scripting on steroids. It is a whole new way to create dynamic content by utilizing the full power of the Apache web server to create stateful sessions, customized user authentication systems, smart proxies and much more. Yet, magically, your old CGI scripts will continue to work and work very fast indeed. With mod_perl you give up nothing and gain so much!
mod_perl bruger CGI til at køre interpreteren, men du kan fint bede den om at køre alle mulige andre scripts, i alle mulige andre sprog. Det kunne være du skulle begynde at læse mere end navnet når du vurderer hvad software gør!
SmackedFly (81) skrev:Processer og tråde er ækvivalente på Unix.
Nej.
Processer og tråde er platformsuafhængige begreber, og de fungerer overordnet set på samme måde i BSD, Linux, Solaris, Windows, på mobiltelefonen osv.
(Ja, selv en 1 kr. mobil-telefon understøtter både processer og tråde, i hvert fald dem der kan køre J2ME, dvs. Java.)
#83
Du må meget gerne fortælle mig hvad forskellen på en process og en tråd er på Linux så. Udover selvfølgelig at begrebet 'process' betyder at den har tråde under sig.
Jeg er godt klar over at de to begreber har deres egne betydninger, jeg siger bare at de fungerer på samme måde. En process på Linux er bare en tråd med en underliggende tråd.
Du må meget gerne fortælle mig hvad forskellen på en process og en tråd er på Linux så. Udover selvfølgelig at begrebet 'process' betyder at den har tråde under sig.
Jeg er godt klar over at de to begreber har deres egne betydninger, jeg siger bare at de fungerer på samme måde. En process på Linux er bare en tråd med en underliggende tråd.
#85
Det fungerer ligesom andre OS'er siger jeg jo. Fx. deler tråde hukommelse (dvs. sætter du en variabel i én tråd, påvirker du alle andre tråde i processen), det gør processer ikke.
Måske tænker du på bash-scripting el. lign? Der har man (vist) slet ikke tråde, kun processer. (Og mange af dem.)
I øvrigt er det noget sludder at sige, at de fungerer på samme måde. Hvis en tråd opfører sig som en process, er det ikke længere en process, og omvendt.
Men der er et hierarki af processer, Dvs. en process kan have en process under sig, som kan have en process under sig osv.
Det fungerer ligesom andre OS'er siger jeg jo. Fx. deler tråde hukommelse (dvs. sætter du en variabel i én tråd, påvirker du alle andre tråde i processen), det gør processer ikke.
Måske tænker du på bash-scripting el. lign? Der har man (vist) slet ikke tråde, kun processer. (Og mange af dem.)
I øvrigt er det noget sludder at sige, at de fungerer på samme måde. Hvis en tråd opfører sig som en process, er det ikke længere en process, og omvendt.
Men der er et hierarki af processer, Dvs. en process kan have en process under sig, som kan have en process under sig osv.
SmackedFly (85) skrev:
Du må meget gerne fortælle mig hvad forskellen på en process og en tråd er på Linux så. Udover selvfølgelig at begrebet 'process' betyder at den har tråde under sig.
Process har hver deres eget virtuelle adresse rum. Tråde deler adresse rum.
Processer og tråde har faktisk ikke meget tilfælles.
SmackedFly (81) skrev:Det mindste du kunne gøre var lige at gå ind og kigge på mod_perls forside inden du sviner mig til.
mod_perl bruger CGI til at køre interpreteren, men du kan fint bede den om at køre alle mulige andre scripts, i alle mulige andre sprog. Det kunne være du skulle begynde at læse mere end navnet når du vurderer hvad software gør!
Nej. Nej. Nej.
mod_perl kører perl i Apache processen og den kan derfor ikke køre vilkårlige Perl scripts.
Det er det som gør at mod_perl er hurtigere end CGI scripts.
NSAPI, ISAPI, Apache modules er alle opfundet af den grund.
mod_perl bruger *ikke* CGI - mod_perl emulerer således at CGI scripts skrevet i Perl fungerer med mod_perl.
Med hensyn til læsning så vil jeg forslå at du læser http://en.wikipedia.org/wiki/Mod_perl:
It embeds a Perl interpreter into the Apache server, so that dynamic content produced by Perl scripts can be served in response to incoming requests, without the significant overhead of re-launching the Perl interpreter for each request.
mod_perl can emulate a CGI environment, so that existing Perl CGI scripts can benefit from the performance boost without having to be re-written.
#89
Jeg gider egentligt ikke diskutere videre før du har sat dig ned og testet det. Jeg har flere gange brugt mod_perl til at ekserkvere rene CGI scripts samt både bash og andet, så jeg er ikke i tvivl om at jeg har ret. Du har fuldstændigt ret i at mod_perl er optimeret til at håndtere perl interpreteren, og gør nogle flere ting for den, men det lavet altså ikke om på at du sagtens kan køre almindellige CGI scripts.. Mod_perl kører CGI scripts, og er væsentligt hurtigere end mod_cgi til det.
Og ja, den gør det ved at emulere CGI igennem perl interpreteren, perl kan sagtens ekserkvere eksterne applikationer, og det er det der sker.
Du er mere end velkommen til at teste det.
Jeg gider egentligt ikke diskutere videre før du har sat dig ned og testet det. Jeg har flere gange brugt mod_perl til at ekserkvere rene CGI scripts samt både bash og andet, så jeg er ikke i tvivl om at jeg har ret. Du har fuldstændigt ret i at mod_perl er optimeret til at håndtere perl interpreteren, og gør nogle flere ting for den, men det lavet altså ikke om på at du sagtens kan køre almindellige CGI scripts.. Mod_perl kører CGI scripts, og er væsentligt hurtigere end mod_cgi til det.
Og ja, den gør det ved at emulere CGI igennem perl interpreteren, perl kan sagtens ekserkvere eksterne applikationer, og det er det der sker.
Du er mere end velkommen til at teste det.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund