Jag har gjort en intranetsida åt ett ganska stort företag och den hostat i deras outsourcade datapark på ett annat företag B.
Företag B tycker nu att det känns osäkert med de funktioner som webbsidan har. DVS ASP-script. Det man kan göra är att redigera html filer med hjälp av ett CMS samt ladda upp filer till en fördefinierad katalog. Detta använder jag FSO och ASPUpload för.
Sedan finns det några CDONTS script för att skicka mail från ett formulär.
Lite databasfunktioner som skriver till en accessdatabas.
Man kan på inga sätt komma utanför sin webbkatalog och ladda upp filer eller spara-html filer utanför sin wwwroot katalog. Det går heller inte att accessa administrationskatalogen där själva administrationen sköts.
Vad ska jag skriva till dem så att de lugnar ner sig? Om de konfigurerat sin server rätt så ska det väl inte vara någon fara eller?
Företag B tycker nu att det känns osäkert med de funktioner som webbsidan har.
Nu? Så de var alltså inte i förväg införstådda med vilka funktioner som skulle finnas eller vilken teknik som skulle användas?
Addeladde skrev:
Man kan på inga sätt komma utanför sin webbkatalog och ladda upp filer eller spara-html filer utanför sin wwwroot katalog. Det går heller inte att accessa administrationskatalogen där själva administrationen sköts.
Om du är helt säker på detta och kan motivera det på ett bra sätt så är det antagligen det du ska skriva.
Addeladde skrev:
Om de konfigurerat sin server rätt så ska det väl inte vara någon fara eller?
Det vet man ju aldrig före nåt händer, men säkerhetshål som inte är relaterade till dina script ligger ju förmodligen utanför ditt ansvarsområde.
Nu? Så de var alltså inte i förväg införstådda med vilka funktioner som skulle finnas eller vilken teknik som skulle användas?
Det var införstådda i att aspupload skulle installeras på servern.
Eftersom man kan ladda upp filer till servern så kan man ju ladda upp sina egna aspscript och sedan köra dem. Men det är ju bara administratörerna som kan ladda upp filer och de har ju tillgång till FTP-kontot ändå.
Om företag B kan sina saker och har gjort allt rätt så behöver dom inte vara oroliga! Även om det finns skrivrättigheter mm!
Jag har skrivt inlägg i IIS-forumet som visar hur man skapar säkra webbplatser, har dom gjort på det sättet så kan inget hända dom(däremot företag A kan råka illa ut om du inte har programmerat bra ;) ) Har dom INTE gjort som jag beskriver i dom inläggen så har dom orsak att oroa sig och då bör företag A byta ställa att ha sitt intranät på!
1. Se till att förebygga sk. SQL-injections.
2. Se till att förebygga SQL-injections, igen.
3. Använd http_referer för att verifiera att scriptet/forumläret verkligen postas från servern och ingen annanstans ifrån.
4. Se till servern har säkerhetspatchar installerade (läs: lämna detta ansvar till någon annan ;))
Se till att använda sessioner snålt, speciellt om det är fel inställningar i servern och flera olika hemsidor ligger på servern. I så fall kan en session som skapats av sajt A skrivas ut på sajt B eller dylikt, vilket icke är att föredra. Med andra ord: företag B måste ha bra säkerhet på sin server. Jag tycker att problemet verkar ligga hos dem.
Om jag inte missminner mig helt så tar du bort '-tecken till och från databasen. Man kan inte sätta in '-tecknet i exempelvis en Access-databas, då blir det error. Annars är det bara att söka på injection här i forumet. :)
Funktion:
<%
Function Fix(str)
str = Replace(str,"'","''")
Fix = str
End Function
%>
Nu använder vi funktionen på variabler som ex. ska in i databasen:
SQL-injections är en typ av säkerhetslucka som måste förebyggas i alla databassystem som tillåter att data från forumlärfält postas "rakt in i" databasen.
T.ex. kan strängen ' or 1=1 ' logga in dig i ett databassystem om programmeraren varit slarvig.
Förebygger detta gör man genom att ersätta en ' (apostrof) med två. Alltså:
user = replace(request.form("user"),"'","''")
passw = replace(request.form("passw"),"'","''")
SQL = "SELECT * FROM users WHERE user = '" & user & "' AND passw = '" & passw & "'"
I så fall kan en session som skapats av sajt A skrivas ut på sajt B eller dylikt, vilket icke är att föredra.
Nej, det där låter lite väl galet för att kunna stämma. Sessioner är och förblir specifika för varje skild webbplats, oavsett om de ligger på samma server eller inte.
I så fall kan en session som skapats av sajt A skrivas ut på sajt B eller dylikt, vilket icke är att föredra.
Nej, det där låter lite väl galet för att kunna stämma. Sessioner är och förblir specifika för varje skild webbplats, oavsett om de ligger på samma server eller inte.
Är det verkligen så? Ifall om man har fel inställningar i servern, eller bara skapar två mappar på servern åt två olika personer som kör ASP utan att låta mapparna vara så att säga "unika" hemsidor, så borde det väl gå? Eller..?
Och ska det inte vara '' i din kod ovan i stället för '''', fyra stycken? /r Åtgärdat! :)
Är det verkligen så? Ifall om man har fel inställningar i servern, eller bara skapar två mappar på servern åt två olika personer som kör ASP utan att låta mapparna vara så att säga "unika" hemsidor, så borde det väl gå? Eller..?
Men då får man också skylla sig själv eftersom det är helt intelligensbefriat att driva ett "webbhotell" på en maskin som inte stödjer multipla och enkilda webbplatser, såsom på en Windows 2000 Professional exempelvis. Då är det klart att alla sessioner delas av alla, de är ju på samma webbplats.
Och ska det inte vara '' i din kod ovan i stället för '''', fyra stycken?
Men då får man också skylla sig själv eftersom det är helt intelligensbefriat att driva ett "webbhotell" på en maskin som inte stödjer multipla och enkilda webbplatser, såsom på en Windows 2000 Professional exempelvis. Då är det klart att alla sessioner delas av alla, de är ju på samma webbplats.
Precis! Det var så jag trodde att det var på mitt "webbhotell" förut, även om jag mycket starkt betvivlar det nu, sedan jag lärt känna min bekants säkerhetsvanor. I det här fallet var jag bara intresserad. :)
SQL-injections är en typ av säkerhetslucka som måste förebyggas i alla databassystem som tillåter att data från forumlärfält postas "rakt in i" databasen.
T.ex. kan strängen ' or 1=1 ' logga in dig i ett databassystem om programmeraren varit slarvig.
Förebygger detta gör man genom att ersätta en ' (apostrof) med två. Alltså:
user = replace(request.form("user"),"'","''")
passw = replace(request.form("passw"),"'","''")
SQL = "SELECT * FROM users WHERE user = '" & user & "' AND passw = '" & passw & "'"
Ja men det viste jag ju såklart att man måste kolla på varje formulärfält. FixaTecken funktionen är ju standard när man kör en insert eller update i en tabell. Visste inte att det kallades SQL-injections bara. :h
Visste inte att det kallades SQL-injections bara. :h
Då vet du det nu! :) Och ett bra ord att kunna är det också, låter proffsigt om man kommer där på företaget eller till polarna och de undrar varför någon har kommit in i deras databas eller dylikt. Då svarar du lite nonchalant: "Du kör inte med SQL-injections va?" och berättar och visar, och sedan är du värsta wiz kid! :e
De vill inte aktivera smtp-tjänsten så att man kan skicka mail med CDONTS från aspsidor. Vad är det som gör det osäkert att aktivera den och vad kan man göra för att förbättra säkerheten om man aktiverar den? Massor av webbhotell har den ju aktiverad.
Är du helt säker på att din FSO-funktion inte kan ställa till det?
FSO klarar av ett och annat tycker jag nog... (Om inte allt är säkert skrivet samt om servern inte stoppar.)
Jag är säker på att mina funktioner inte kan ställa till det men eftersom publiceringsverktyget är byggt så att man kan använda asp-script i det samt att man kan ladda upp asp-filer så kan man ju bygga skadliga script själv och sedan köra dem. Men de som kan göra det är ju administratörerna och har ju redan tillgång till ftp-uppgifterna för webbplatsen så de skulle lika gärna kunna göra det den vägen.
Men FSO bråkar de inte om längre. Vad är det med SMTP-tjänsten som är så farligt? Går det inte att konfigurera den så att endast webbsidan kan skicka mail?
305 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2
