---

I forbindelse med en research til en lille artikel om querystring
injection og cross scipt scripting er jeg faldet over disse
betegnelser; parameterized queries og stored procedures.

Er der nogen, som på god dansk kan give en letforståelig forklaring
på, hvordan de virker? De artikler, jeg har fundet, har ikke været
sådan lige til at gå til;)

Så vidt jeg er orienteret, er det metoder, man bruger til sikkerheden
i databaser, og da jeg snart skal i gang med netop DB, vil det også
være aktuelt dér.



MVH
Rune Jensen

---

"Rune Jensen" <runeofdenmark@gmail.com> wrote in message
news:dedcc4e1-dad4-43ab-aed5-b5cfc7794b44@56g2000hsm.googlegroups.com...
>I forbindelse med en research til en lille artikel om querystring
>injection og cross scipt scripting er jeg faldet over disse
>betegnelser; parameterized queries og stored procedures.

Det har kun noget med databaser at gøre, Querystring er en ASP streng,
hvorimod Queries er SQL udtryk/sætninger.

>Er der nogen, som på god dansk kan give en letforståelig forklaring
>på, hvordan de virker? De artikler, jeg har fundet, har ikke været
>sådan lige til at gå til;)

>Så vidt jeg er orienteret, er det metoder, man bruger til sikkerheden
>i databaser, og da jeg snart skal i gang med netop DB, vil det også
>være aktuelt dér.

Stored procedures kan du nogenlunde sammenligne med et ASP funktion.
Der er tale om 'programstumper', der gemmes i databasen for at 'lette'
programmeringen. Sikkerhedsmæssigt er der ingen forskel på om det er stored
procedures eller ej.

Parameterized queries, eller prepared queries, som det også bliver kaldt er
brug af parametre i SQL'et i stedet for at benytte feltindholdet direkte.

Eksempel:
Hvis vi har en variabel der hedder MessageBody som vi gerne vil indsætte i
tabellen Messages, kan man skrive:
sql = "INSERT INTO Messages VALUES('"+MessageBody+"')"
Hvis man skriver "hej" i feltet vil det blive til:
INSERT INTO Messages VALUES('hej')
Bemærk her, at strengfelter omgive af '.
Hvis man så skriver "don't" i felter bliver det til:
INSERT INTO Messages VALUES('don't')
det vil fejle fordi serveren opfatter 'don' som værdien, og t' er i
"overskud".
Man kan så replace forekomster af ' med ''(=2 '), som fortolkes korrekt af
serveren, så i det tilfælde vil det blive til:
INSERT INTO Messages VALUES('don''t')
Sikkerhedsmæssigt, nå vi snakker SQL injection, går det ud på at forsøge
forskellige konstruktioner af ' for at fosøge at bryde ind.
Hvis man ikke replacer 'erne vil man kunne skrive eksempelvis:
"don'); drop table users ; --" i feltet, og tabellen users vil være
forsvundet.

I stedet for replace bør man bruge paramaterized queries, hvor man i stedet
for ovenstående sql bruger:
sql = "INSERT INTO Messages VALUES(?)"
Hvert ? angiver en parameter, og i asp skriver man så:
AdoCommandMessage.CommandText = sql
AdoCommandMessage(0) = MessageBody
AdoCommandMessage.Execute

På den måde bliver indholdet af MessageBody slet ikke blandet ind i SQL
sætningen, så der er ingen mulighed for injection af nogen art.
Sikkerhedsmæssigt er der heller ikke behov for nogen inputvalidering.

Spam mæssigt bør man dog lave nogle regler.

De samme ting gælder for kald af stored procedures, der bare er en anden
udformning af SQL udtrykket.

--
Med venlig hilsen/Best regards
Stig Johansen

---

On 4 Jun., 22:51, "Stig Johansen" <wopr...@gmail.com> wrote:

(KLIP)
> Sikkerhedsmæssigt er der ingen forskel på om det er stored
> procedures eller ej.

Så vil jeg holde spørgsmålene til parameterized queries foreløbig


(KLIP)
> Sikkerhedsmæssigt, nå vi snakker SQL injection, går det ud på at forsøge
> forskellige konstruktioner af ' for at fosøge at bryde ind.
> Hvis man ikke replacer 'erne vil man kunne skrive eksempelvis:
> "don'); drop table users ; --" i feltet, og tabellen users vil være
> forsvundet.

Det er meget forståeligt. Jeg tror, der hvor jeg går galt i byen er,
hvordan de kan injecte den malicious code. Altså, det kan foregå i
POST via en form, men vel også via GET i en querystring?

Jeg fandt denne, og selv om jeg ikke synes, den burde virke, så laver
den de fejl, den beskriver, når jeg afprøver på egen side:
http://www.webappsec.org/projects/threat/classes/sql_injection.shtml

?variabel=2+union+all+select+name+from+sysobjects
...giver f.eks. infinite loop i Opera og fejl i FF. Variabelnavnet er
ligegyldigt idf.

Men kan man lave SQL injection på den måde, eller er det kun for at
finde sårbarheden man bruger querystring? Jeg får jo jævnligt en del
hackingforsøg, som ligner dem i linket.


> I stedet for replace bør man bruge paramaterized queries, hvor man i stedet
> for ovenstående sql bruger:
> sql = "INSERT INTO Messages VALUES(?)"
> Hvert ? angiver en parameter, og i asp skriver man så:
> AdoCommandMessage.CommandText = sql
> AdoCommandMessage(0) = MessageBody
> AdoCommandMessage.Execute
>
> På den måde bliver indholdet af MessageBody slet ikke blandet ind i SQL
> sætningen, så der er ingen mulighed for injection af nogen art.

Lyder rigtigt, og jeg forstår meningen, men ikke kommandoerne. Det må
komme, når jeg begynder på DB. Bare, der er en sikker metode.


> Sikkerhedsmæssigt er der heller ikke behov for nogen inputvalidering.

Jo mere, man kan undlade og stadig beholde sikkerheden, des bedre. Men
jeg plejer nu også at validere inputs pga. HTML-injection.


> Spam mæssigt bør man dog lave nogle regler.

Ja, det er klart.
Tak for svarene Stig, jeg må lige nærlæse dem, når jeg er mere vågen
end nu, sidder og klipper kaninr.


MVH
Rune Jensen

---

Rune Jensen wrote:
> On 4 Jun., 22:51, "Stig Johansen" <wopr...@gmail.com> wrote:
>
> (KLIP)
>> Sikkerhedsmæssigt er der ingen forskel på om det er stored
>> procedures eller ej.
>
> Så vil jeg holde spørgsmålene til parameterized queries foreløbig
>
>
> (KLIP)
>> Sikkerhedsmæssigt, nå vi snakker SQL injection, går det ud på at
>> forsøge forskellige konstruktioner af ' for at fosøge at bryde ind.
>> Hvis man ikke replacer 'erne vil man kunne skrive eksempelvis:
>> "don'); drop table users ; --" i feltet, og tabellen users vil være
>> forsvundet.
>
> Det er meget forståeligt. Jeg tror, der hvor jeg går galt i byen er,
> hvordan de kan injecte den malicious code. Altså, det kan foregå i
> POST via en form, men vel også via GET i en querystring?
>
> Jeg fandt denne, og selv om jeg ikke synes, den burde virke, så laver
> den de fejl, den beskriver, når jeg afprøver på egen side:
> http://www.webappsec.org/projects/threat/classes/sql_injection.shtml
>
> ?variabel=2+union+all+select+name+from+sysobjects
> ...giver f.eks. infinite loop i Opera og fejl i FF. Variabelnavnet er
> ligegyldigt idf.
>
> Men kan man lave SQL injection på den måde, eller er det kun for at
> finde sårbarheden man bruger querystring? Jeg får jo jævnligt en del
> hackingforsøg, som ligner dem i linket.
>
>
>> I stedet for replace bør man bruge paramaterized queries, hvor man i
>> stedet for ovenstående sql bruger:
>> sql = "INSERT INTO Messages VALUES(?)"
>> Hvert ? angiver en parameter, og i asp skriver man så:
>> AdoCommandMessage.CommandText = sql
>> AdoCommandMessage(0) = MessageBody
>> AdoCommandMessage.Execute
>>
>> På den måde bliver indholdet af MessageBody slet ikke blandet ind i
>> SQL sætningen, så der er ingen mulighed for injection af nogen art.
>
> Lyder rigtigt, og jeg forstår meningen, men ikke kommandoerne. Det må
> komme, når jeg begynder på DB. Bare, der er en sikker metode.


Du kan se klasser og kommandoer her :
http://www.w3schools.com/ado/default.asp

---

On Wed, 4 Jun 2008 16:35:34 -0700 (PDT), Rune Jensen
<runeofdenmark@gmail.com> wrote:

>On 4 Jun., 22:51, "Stig Johansen" <wopr...@gmail.com> wrote:
>Jeg fandt denne, og selv om jeg ikke synes, den burde virke, så laver
>den de fejl, den beskriver, når jeg afprøver på egen side:
>http://www.webappsec.org/projects/threat/classes/sql_injection.shtml
>
>?variabel=2+union+all+select+name+from+sysobjects
>...giver f.eks. infinite loop i Opera og fejl i FF. Variabelnavnet er
>ligegyldigt idf.
>
>Men kan man lave SQL injection på den måde, eller er det kun for at
>finde sårbarheden man bruger querystring?

Hvis man glemmer at tænke sig om og fx bruger:
minVar = Request("var")
- og så vil man både kunne kunne få input med POST og GET.
Brug derfor altid specifikt Request.Form, .QueryString eller hvad der nu
skal bruges.

Et "ondsindet" angreb vil næsten altid forsøge den simpleste metode
først - og hvis man kan hente alle tabelnavne med en simpel
query-streng, så kan det næsten ikke være lettere



Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

Rune Jensen wrote:

> On 4 Jun., 22:51, "Stig Johansen" <wopr...@gmail.com> wrote:
> (KLIP)
>> Sikkerhedsmæssigt, nå vi snakker SQL injection, går det ud på at forsøge
>> forskellige konstruktioner af ' for at fosøge at bryde ind.
>> Hvis man ikke replacer 'erne vil man kunne skrive eksempelvis:
>> "don'); drop table users ; --" i feltet, og tabellen users vil være
>> forsvundet.
>
> Det er meget forståeligt. Jeg tror, der hvor jeg går galt i byen er,
> hvordan de kan injecte den malicious code. Altså, det kan foregå i
> POST via en form, men vel også via GET i en querystring?

Det kan foregå både med POST og med GET.
Men det er stadig op til programmet om det er det ene eller det andet.
Hvis man bruger Request.Form("xxx") som basis for sin SQL, er det POST
ellers hvis man bruger Request.Querystring er det via GET.

> Jeg fandt denne, og selv om jeg ikke synes, den burde virke, så laver
> den de fejl, den beskriver, når jeg afprøver på egen side:
> http://www.webappsec.org/projects/threat/classes/sql_injection.shtml
>
> ?variabel=2+union+all+select+name+from+sysobjects
> ...giver f.eks. infinite loop i Opera og fejl i FF. Variabelnavnet er
> ligegyldigt idf.
>
> Men kan man lave SQL injection på den måde, eller er det kun for at
> finde sårbarheden man bruger querystring?

Den der er sådan set ikke SQL injection men sysobjects indeholder
informationer om den interne struktur i MS SQLServer, så hvis den 'går
godt' vil men få en liste med en masse dejlige oplysninger.
Disse oplysninger kan man så bruge til egentlig Injection.

> Jeg får jo jævnligt en del
> hackingforsøg, som ligner dem i linket.

'Kineseren' ?
Den skyder med spredhagl, og prøver både med og uden ' i starten.
Jeg vil gætte på, at alle de steder der lykkes, er der hvor man har overset,
at selv en primitiv søgning på tal kan være sårbar.

> Lyder rigtigt, og jeg forstår meningen, men ikke kommandoerne. Det må
> komme, når jeg begynder på DB. Bare, der er en sikker metode.

Den sikre metoder er: Brug _altid_ parameterized queries, også ved simple
søgninger.
Hvis du gør det behøver du slet ikke læse om SQL injection, da det ikke kan
lade sig gøre.

Problemet er højst sandsynligt, at det kræver ekstra kodning, som man ikke
gider, eller måske ikke kender til parameterized queries.

>> Sikkerhedsmæssigt er der heller ikke behov for nogen inputvalidering.
>
> Jo mere, man kan undlade og stadig beholde sikkerheden, des bedre.

Det var lidt ordkløveri fra min side. Der er lidt diskussion om eks. spam er
_sikkerhed_.

Jeg har så lidt den modsatte holdning:
Jo mere man kan få med og stadig beholde sikkerheden, jo bedre.

Jeg har set forsøg på clientside inputvalidering, som mere eller mindre
gjorde systemet ubrugeligt.

(For en god ordens skyld vil jeg _ikke_ nævne at det var et konsortium af
Microsoft og Accenture, der stod for leverancen

> Men
> jeg plejer nu også at validere inputs pga. HTML-injection.

Man kan også vælge at bibeholde input råt, og XMLEncode output, så er dén
ged barberet.


--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" skrev

> Den sikre metoder er: Brug _altid_ parameterized queries, også ved simple
> søgninger.

Hvis man bruger MSSQL og fedter lidt med profileren vil man opdage at brug
af ADODB.Command objectet giver nogle forbedringer på performance da kaldet
til databasen bliver udført på en anden måde

> Problemet er højst sandsynligt, at det kræver ekstra kodning,

Man har vel lavet et database layer

> eller måske ikke kender til parameterized queries.

Nok mere sandsynligt

- Peter

---

Peter Lykkegaard wrote:

> "Stig Johansen" skrev
>
>> Den sikre metoder er: Brug _altid_ parameterized queries, også ved simple
>> søgninger.
>
> Hvis man bruger MSSQL og fedter lidt med profileren vil man opdage at brug
> af ADODB.Command objectet giver nogle forbedringer på performance da
> kaldet til databasen bliver udført på en anden måde

Nu ved jeg ikke hvem 'man' er, og/eller om du svarer mig, men jeg har (også)
brugt MS SQLServer siden '95-'96.

Jeg vil nok reformulere det til
"ADODB.Command _kan_ give nogle forbedringer.."

Et thin layer ODBC kan give ligeså god, og måske endda bedre performance.
(Hint: se DTS).

>> Problemet er højst sandsynligt, at det kræver ekstra kodning,
>
> Man har vel lavet et database layer

ADO er vel database layeret i ASP eller ?
Det ændre ikke ved, at man skal lave mindst een kodelinie for hver
parameter.

>> eller måske ikke kender til parameterized queries.
>
> Nok mere sandsynligt

Ok, min egen teori er
"Til vished grænsende sandsynlighed".

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" skrev

> Nu ved jeg ikke hvem 'man' er, og/eller om du svarer mig

Det var en generelt betragtning

> Jeg vil nok reformulere det til
> "ADODB.Command _kan_ give nogle forbedringer.."
>
Kikker man stringent på ADO så er command objectet den tilgang der giver
bedst performance

> Et thin layer ODBC kan give ligeså god, og måske endda bedre performance.
> (Hint: se DTS).

Data Transformation Services?
>
> ADO er vel database layeret i ASP eller ?

ADO (Active Data Objects) er MS' tilgang til databaser, generelt set

Jeg mente en række interface der adskiller databaseadgang og
forretningslogik
(Hvis man vælger at placere forretningslogik i SP's så bliver det hele mere
bøvlet med forskellige layers)

- Peter

---

Peter Lykkegaard wrote:
> "Stig Johansen" skrev
>
>> Nu ved jeg ikke hvem 'man' er, og/eller om du svarer mig
>
> Det var en generelt betragtning
>
>> Jeg vil nok reformulere det til
>> "ADODB.Command _kan_ give nogle forbedringer.."
>>
> Kikker man stringent på ADO så er command objectet den tilgang der
> giver bedst performance
>
>> Et thin layer ODBC kan give ligeså god, og måske endda bedre
>> performance. (Hint: se DTS).
>
> Data Transformation Services?
>>
>> ADO er vel database layeret i ASP eller ?
>
> ADO (Active Data Objects) er MS' tilgang til databaser, generelt set
>
> Jeg mente en række interface der adskiller databaseadgang og
> forretningslogik
> (Hvis man vælger at placere forretningslogik i SP's så bliver det
> hele mere bøvlet med forskellige layers)

Et Data Access Layer ?
http://en.wikipedia.org/wiki/Data_access_layer
;)

---

Peter Lykkegaard wrote:

> Kikker man stringent på ADO så er command objectet den tilgang der giver
> bedst performance

De ting man kan klare direkte på connection objectet giver nu bedre
performance, men never mind.

>> Et thin layer ODBC kan give ligeså god, og måske endda bedre performance.
>> (Hint: se DTS).
>
> Data Transformation Services?

Ja, DTS - i hvertfald i de tidlige inkarnationer - bruger/brugte ODBC
(primært bulk copy/insert), for at opnå en god performance.

>> ADO er vel database layeret i ASP eller ?
>
> ADO (Active Data Objects) er MS' tilgang til databaser, generelt set
> Jeg mente en række interface der adskiller databaseadgang og
> forretningslogik

aka. multitier løsninger, men det er vist ikke i .ASP gruppen det hører
hjemme.

> (Hvis man vælger at placere forretningslogik i SP's så bliver det hele
> mere bøvlet med forskellige layers)

Min uforbeholdne mening er:
Hvis man placerer forretningslogik i SP'ere så har man selv ladt begge
pistoler, trykket på aftrækkerne, og er selv ude om, at man har skudt alle
fødderne af sig selv til lidt over knæene.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Peter Lykkegaard wrote:
[snip]
>> (Hvis man vælger at placere forretningslogik i SP's så bliver det
>> hele mere bøvlet med forskellige layers)
>
> Min uforbeholdne mening er:
> Hvis man placerer forretningslogik i SP'ere så har man selv ladt begge
> pistoler, trykket på aftrækkerne, og er selv ude om, at man har skudt
> alle fødderne af sig selv til lidt over knæene.


Kunne du prøve at uddybe det synspunkt.

---

Michael Weber wrote:

> Stig Johansen wrote:
>> Peter Lykkegaard wrote:
> [snip]
>>> (Hvis man vælger at placere forretningslogik i SP's så bliver det
>>> hele mere bøvlet med forskellige layers)
>>
>> Min uforbeholdne mening er:
>> Hvis man placerer forretningslogik i SP'ere så har man selv ladt begge
>> pistoler, trykket på aftrækkerne, og er selv ude om, at man har skudt
>> alle fødderne af sig selv til lidt over knæene.
>
>
> Kunne du prøve at uddybe det synspunkt.

Kode - versionsstyring - vedligeholdelse - change management - hvor ligger
hvad, og hvem laver hvad, og hvorfor? udviklerne, DBA'erne eller ?

Den korte version: Dobbelt vedligeholdelse.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" skrev

> aka. multitier løsninger, men det er vist ikke i .ASP gruppen det hører
> hjemme.

Hvorfor ikke?
Jeg har lavet ASP løsninger hvor dataadgang var lagt i et underliggende lag
>
>> (Hvis man vælger at placere forretningslogik i SP's så bliver det hele
>> mere bøvlet med forskellige layers)
>
> Min uforbeholdne mening er:
> Hvis man placerer forretningslogik i SP'ere så har man selv ladt begge
> pistoler, trykket på aftrækkerne, og er selv ude om, at man har skudt alle
> fødderne af sig selv til lidt over knæene.
>
Jeg har fået trukket noget middleware ned over hovedet hvor en del af
forretningslogikken ligger i et hierarki af SP's. Der er samtidig lavet et
databaselayer hvor man skal ændre interfaces hver gang man skal justere lidt
på en SP
Jeg har nu på den hårde måde lært præcist hvorfor forretningslogik ikke
hører til i SP's

- Peter

---

Peter Lykkegaard wrote:
> "Stig Johansen" skrev
>
>> Den sikre metoder er: Brug _altid_ parameterized queries, også ved
>> simple søgninger.
>
> Hvis man bruger MSSQL og fedter lidt med profileren vil man opdage at
> brug af ADODB.Command objectet giver nogle forbedringer på
> performance da kaldet til databasen bliver udført på en anden måde

Så vidt jeg husker fordi man rent faktisk esekverer
stored proceduren sp_executesql. (ihvertfald fra .NET)
http://groups.google.dk/group/dk.edb.programmering.dotnet/browse_thread/thre
ad/3d89e04d63d7b2cd/a29dfb1056ca5efc?hl=da&lnk=gst&q=Weber+profiler#a29dfb10
56ca5efc

:)

---

"Michael Weber" skrev

> Så vidt jeg husker fordi man rent faktisk esekverer
> stored proceduren sp_executesql.

Njahh MSSQL bliver kaldt på 2 forskellige måder og samtidig har command
objectet mindre overhead end fx recordset.open
Forsøget er ret enkelt at lave med MSSQL profiler og nogle linier kode

- Peter

---

On 5 Jun., 09:53, "Peter Lykkegaard" <plykkega...@gmail.com> wrote:
> "Stig Johansen" skrev
>
> > Den sikre metoder er: Brug _altid_ parameterized queries, også ved simple
> > søgninger.

Hvis jeg har noget enkelt at holde mig til, så er det OK. Ikke fordi
jeg ikke har lyst til at lære om SQL-injections, men jeg har ikke så
meget tid lige for øjeblikket, og det kan godt blive besværligt at
sætte sig ind i alt. Så hvis det kan ordnes med at lære parameterized
queries, er det fair nok foreløbig.

> Hvis man bruger MSSQL og fedter lidt med profileren vil man opdage at brug
> af ADODB.Command objectet giver nogle forbedringer på performance da kaldet
> til databasen bliver udført på en anden måde
>
> > Problemet er højst sandsynligt, at det kræver ekstra kodning,
>
> Man har vel lavet et database layer

Er database layer noget, man kan forstå/sætte sig ind i "på forhånd"
eller skal man lære det mens man lærer database? Jeg tænker på, hvor
komplekst det er, om der er nogle simple regler, man bare kan følge.


MVH
Rune Jensen

---

On 5 Jun., 07:44, Stig Johansen <wopr...@gmaill.com> wrote:
> Rune Jensen wrote:

> >> Sikkerhedsmæssigt er der heller ikke behov for nogen inputvalidering.
>
> > Jo mere, man kan undlade og stadig beholde sikkerheden, des bedre.
>
> Det var lidt ordkløveri fra min side. Der er lidt diskussion om eks. spam er
> _sikkerhed_.

Mja... Jeg faldt over en side, som gav en beskrivelse af XSS
scripting.
http://infinityexists.com/
Lavede en iframe injection via en form i et forum. Det var rigtigt
kløgtigt. Men reelt kan man vel via referrer spam lave et link som
prøver at installere malicious code. Jeg mener reelt kan al spam jo
være sådanne links i stedet. Men det har så nok ikke som sådan noget
at gøre med SQL-injection.

> Jeg har så lidt den modsatte holdning:
> Jo mere man kan få med og stadig beholde sikkerheden, jo bedre.

Det tror jeg også du har ret i, men så kender man vel også sin kode
(og jeg har et par huller hist og her). Jeg kan forestille mig, det
kræver ret god disciplin at have det hele i klartekst.

> Jeg har set forsøg på clientside inputvalidering, som mere eller mindre
> gjorde systemet ubrugeligt.

...Clientside validering er jo ikke nok;) Hackere slår da bare
JavaScript fra.

> (For en god ordens skyld vil jeg _ikke_ nævne at det var et konsortium af
> Microsoft og Accenture, der stod for leverancen

Sikkerhed koster penge og tid, og man kan ikke se det ved alm. kørsel,
så der slækkes godt og grundigt på det i mange firmaer (det er mit
indtryk i hvert fald). Det er det samme med validering af HTML/CSS og
user tests (usability). Det bliver nedprioriteret.

> > Men
> > jeg plejer nu også at validere inputs pga. HTML-injection.
>
> Man kan også vælge at bibeholde input råt, og XMLEncode output, så er dén
> ged barberet.

Ja, og jeg forstår argumentet, som jeg så også er enig i. Jeg skal
også have lavet om i kodningen på en del af min side. Jeg vil bare
være sikker hver gang jeg gør noget, at der ikke er sikkerhedshuller.


MVH
Rune Jensen

---

On 6 Jun., 07:48, Stig Johansen <wopr...@gmaill.com> wrote:
> Peter Lykkegaard wrote:
> > "Stig Johansen" skrev

> >>  eller måske ikke kender til parameterized queries.
>
> > Nok mere sandsynligt
>
> Ok, min egen teori er
> "Til vished grænsende sandsynlighed".

Hvorfor? Er det så avanceret, man ikke lærer om det på de forskelige
datalogiuddannelser? Hvor lærer man det så - er der specialuddanelse
til det (altså sikkerhed generelt også)? Hvis man hyrer en til
database, så må man vel gå ud fra, denne også kan gøre det
sikkerhedsmæssigt forsvarligt?

Kommer til at tænke på, da FNs hjemmeside blev defaced. Det er da
pinligt, man kan bryde ind så forholdsvist nemt. Og de er ikke engang
de eneste!


MVH
Rune Jensen

---

"Rune Jensen" skrev

> Hvorfor? Er det så avanceret

Det er ikke særlig avanceret (imo)

>, man ikke lærer om det på de forskelige
> datalogiuddannelser?

Datalogi handler en del om teori knap så meget om praktik

> Hvor lærer man det så - er der specialuddanelse

Ikke som sådan
Hvert værktøj har (delvist) sin egen måde at implementere det på

> til det (altså sikkerhed generelt også)? Hvis man hyrer en til
> database, så må man vel gå ud fra, denne også kan gøre det
> sikkerhedsmæssigt forsvarligt?
>
Det ligger forhåbentligt i din specification mht hvad der skal laves?
I it-branchen går tingene som regel på at det skal være billigst muligt ikke
bedst muligt
Prisen afspejler som regel hvor meget (læs lidt) der bliver lavet

Vil du køre din bil til mekanikeren uden at specificere hvad der skal
laves/skiftes eller få et en fast pris?
Du kan være sikker på at regningen vil være en overraskelse af de større

- Peter

---

On 6 Jun., 11:45, "Peter Lykkegaard" <plykkega...@gmail.com> wrote:
> "Rune Jensen" skrev

> > til det (altså sikkerhed generelt også)? Hvis man hyrer en til
> > database, så må man vel gå ud fra, denne også kan gøre det
> > sikkerhedsmæssigt forsvarligt?
>
> Det ligger forhåbentligt i din specification mht hvad der skal laves?
> I it-branchen går tingene som regel på at det skal være billigst muligt ikke
> bedst muligt
> Prisen afspejler som regel hvor meget (læs lidt) der bliver lavet

Jeg har haft mistanke om det længe - nu jeg ikke selv er i branchen
som prof men kun på hobbyplan, har jeg jo kun kunnet kigge på det,
andre har lavet og så sammenligne med min egen viden. Spørgsmålet går
nok mest på, om det, man lærer, er rent generelt, eller om man får de
værktøjer, som skal med (efter min mening) om f.eks. sikkerhed. Så er
det pga. manglende penge, eller pga. manglende viden, man ikke sikrer
sig...


MVH
Rune Jensen

---

"Rune Jensen" skrev

> Så er det pga. manglende penge, eller pga. manglende viden,
> man ikke sikrer sig...

Du kan ikke sætte det op på den måde
Et eks

Mit elpanel i privaten skulle udskiftes
Jeg bestiller en elektriker men "glemmer" at få en fastpris (min fejl - jeg
tænkte hvor svært kan det være)
Overslag 2k - regning = 4k
Havde jeg fået en fastpris havde elektrikeren forsøgt at lave det på kortere
tid sandsynligvis med større risiko for fejl/mangler

Sådan er det i de fleste brancher
Uden en detaljeret specifikation på de ting der skal laves er tingene dømt
til at gå galt på den ene eller anden måde

- Peter

---

On 6 Jun., 20:27, "Peter Lykkegaard" <plykkega...@gmail.com> wrote:
> "Michael Weber" skrev
>
> > Så vidt jeg husker fordi man rent faktisk esekverer
> > stored proceduren sp_executesql.
>
> Njahh MSSQL bliver kaldt på 2 forskellige måder og samtidig har command
> objectet mindre overhead end fx recordset.open
> Forsøget er ret enkelt at lave med MSSQL profiler og nogle linier kode

Tak til jer alle for besvarelser. Det sidste er nok lidt for avanceret
for mig, men anyway, hvis nu man vil lære tingene "the right way" om
databaser, hvor går man så hen? Er der nogle gode hjemmesider, man kan
starte på?


MVH
Rune Jensen