kontroller on includefil er included

Man kan, hvis webserveren/hotellet tillader, lægge filer, der ikke skal kunne tilgås udefra i et katalog, der ikke kan ses udefra.

Jamen, du har jo ret. De skal jo bare over i kataloget sammen med databaserne etc...
som ikke kan ses ude fra.
Du må gerne smide et svar, så får du den.
Men jeg kunne godt tænke mig noget mere info omkring sikerheden med ASP, databaser etc...
Jeg har fundet et par links, hvis nogen skulle være interesseret.
http://www.4guysfromrolla.com/webtech/LearnMore/Security.asp
Og så er der en tilføjelse til firefox "hackbar" den tjekker de mest alm. sql-injections

"sikerheden med ASP" - var det ikke på tide at droppe ASP, og lære alt det nye?
Jeg samler slet ikke på points, tak. Svar selv, accepter dit eget svar.

Det han søger er en svaghed i din kode, så han kan komme til din db.

Vi har haft samme problem ude ved os og kommet frem til følgende foranstaltninger:
1. 2 db brugere. En som kun kan læse og en som både kan læse og skrive. Læse/skrive brugeren er kun sat ind hvor det er absolut nødvendigt
2. Lavet et script som tjekker på forskellige SQL-injections problemer og redirecter til en forside og sat ind på de sider der har skriverettigheder.
3. tjekker på ALT i request.

Forresten undgå at hente flere felter end du har brug for i din SQL, samt undgå SELECT *

Ikke forstået? Man kontrollerer ikke noget som helst om SQL-injections, ved at kontrollere input. Det kan være man gjorde for 10 år siden.

"Problemet" med SQL-injections håndteres ved SQL-en, hvor man med parameters, prepared statements, eller hvad de nu hedder, sørger for at SQL-injections ikke er noget problem.

Og ja, det kan man faktisk også i gammeldags ASP.

Mener man, at man er nødt til at TESTE for SQL-injections, så er man helt ude på herrens mark, og vil tjene sagen bedst ved at skrotte koden og starte forfra.

10 år siden eller ej, problemet er den samme. Hvis man har en del gammel kode, til gamle websites, hvor kunden ikke ønsker at betale for en opdatering, vil der ikke være penge til at lave ny kode fra bunden.

Du skal huske på at man kan åbne recordset på MANGE forskellige måder, derfor kan der være metoder hvor man ikke har parametre, men at det hele er direkte i SQL sætningen. og der er her det bliver farligt. Når du bruger parametre er det netop noget lignende du laver.

Hver programmør har sin egen metode forskellige ting, og lave kode om for hver af dem, vil være en bekostelig affære. Der kan det være billigst at lave ovenstående.

SQL-injections bliver netop lavet med input (querystrings).

Nej. Forsøg på SQL-injections bliver lavet via input, men forsøgene er virkningsløse, hvis man har lavet det rigtigt. Ja, der er gammel kode derude, fra folk der ikke ved hvad de foretog sig.

Jeg er ikke helt med mere. Hvor henne er vi uenige?

Parametiseret SQL løser desværre ikke problemet 100%. Det gør det sværere, så man undgår de mest simple sql injections.

Hvis man fx har et input af typen varchar, er databasen faktisk stadig usikker. Det gælder om at det man sender til DB-engine (input), ikke indeholder kode der stopper ens oprindelige forespørgsel, og starte en anden forespørgsel (typisk ved at fremprovokere en fejl og så starte en ny via indlejret sql).

Hvis du vil være sikker, bliver du nød til at tjekke om der ikke er skadeligt kode i det du sendet til din db engine.

Hvis du har et eksempel, er jeg meget nysgerrig, erikjacobsen.

"Parametiseret SQL løser desværre ikke problemet 100%. " - jeg synes du skal komme med et eksempel.

Hmmm, diskuterer vi bare for at diskutere. Det har jeg for lidt tid til så det bliver mit sidste indslag i denne tråd. Jeg ser dog frem til et eksempel erikjacobsen. Ikke så meget for at sige "Jeg har ret", men mere fordi jeg er nysgerrig.

Der er masser af eksempler der ude på parametiseret SQL der ikke er 100% sikre, fx
http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/10/13/28370.aspx

Søg på nettet for flere, og du vil se.

Et tilfældigt link en tilfældig person har skrevet, er jo ikke nødvendigvis korrekt.

Men det link siger jo præcis hvad jeg siger. Der kommer en mærkelig påstand: "Don’t make the mistake of thinking that security alone will prevent users from performing a successful SQL injection."  Hvad mener han med "security" ?

Og han mener forhåbentlig ikke at "And most importantly: Always validate user input. " betyder at man skal kontrollere for SQL-injection i user input.

Vi diskuterer sandelig ikke for diskussionens skyld.

Du siger at noget ikke løser problemet 100%. Hvis problemet er SQL-injection, så mener jeg at det løses 100% - hvordan skal jeg kommer med et eksempel på det. Du mener så at det ikke er løst 100%, og så må du komme med et eksempel, så vi kan bliver klogere.

sorry