av ·0 kommentarer

På sistone har det hänt att jag har behövt felsöka PHP loggfiler eller HTTP loggfiler p.g.a. att hemsidan kanske kraschat via PHP Fatal Error eller p.g.a. DDoS-attacker.

DDoS-attacker mot hemsidor och vad man kan göra när de inträffar

DDoS-attacker är vanligare än man kanske tror och kanske mer så för populära och större hemsidor – tyvärr.

Det finns tillochmed företag inom affärsvärlden som anlitar folk för att sänka konkurrenter genom att ha dem skicka ut kodade bottar för att överbelasta hemsidor på olika sätt.

Ofta brukar detta dock vara olagligt, men kanske inte alltid så lätt att spåra ursprunget och komma fram till vem som ligger bakom.

Jag har erfarenhet av att ha stött på bottar utskickade från andra länder, kodade att överbelasta hemsidan på olika sätt.

En bot kan relativt enkelt (tyvärr) överbelasta en hemsida

En av de här bottarna gjorde det genom att låta botten basically ”klicka runt” på hemsidan så snabbt som bottens maskins processor klarade av.

Och vår server kunde inte hänga med.

Tänk dig själv hundratals- om inte tusentals klick på millisekunden på din hemsida. Där varje klick motsvarade anrop till servern, för handling som behövde tas av den.

Anrop som ofta involverade SQL-frågor till databasen, JavaScript funktioner att laddas och köras eller sidor att generera och laddas.

Det krävs inte ”rocket science” att lista ut att detta lätt överbelastar en servermaskins RAM-minne, processorkraft och övriga resurser, som annars delas mellan alla besökare till en hemsida.

Och skapar köer så långa att hemsidan till slut blir otillgänglig medan servern försöker hantera belastningen den utsatts för.

Om man tänker efter så behöver det inte vara så komplicerat att bygga något som kan förstöra för en hemsida, men det är synd att folk gör det och att det är så lätt för dem att åstadkomma det och komma undan med det.

Där finns en väldigt bra bok jag köpte för några år sen och läste för Hur man bygger Spiders, Bottar osv. skriven av en som arbetade professionellt med att enbart bygga bottar för olika affärsändamål som företag hade behov av.

Det kunde vara ändamål som att indexera priser från konkurrenters hemsidor, eller automatisera testkörning av formulär på olika hemsidor, och liknande.

Men då varje bot du bygger kommer köra så snabbt som processorn klarar av – om du inte säger till den något annat- så hade denna författaren som best praxis och regel alltid när han byggde bottar att ”simulera en människans beteende”.

Med detta menas för när en människa besöker hemsidor och hur ”fort” de då gör olika saker på en hemsida.

Han simulerade detta genom att lägga in någon sekunds delay mellan varje datahämtning.

  • Dels för att inte skada servern för hemsidan han arbetade mot med sina bottar
  • Dels då det är olagligt att krascha hemsidors servrar
  • Dels för att vara ”under radarn” och inte ge kanske konkurrenter osv. anledning att kolla närmare på hans bott och dess beteende

Boken är ”Webbots, Spiders, and Screen Scrapers: A Guide to Developing Internet Agents with PHP / CURL” av Michael Schrenk.

webbots, spiders, and screen scrapers bok av Michael Schrenk

Kan varmt rekommendera boken för alla er nyfikna på hur man bygger Bot programvara med PHP. Enklare än man tror, på gott och ont.

Om inget annat så kan boken öppna ögonen och utöka förståelsen för vad en bot faktiskt kan åstadkomma på en hemsida, och hur, vilket även kan hjälpa till när du ska analysera och skydda dig från dem.

”Know Thy Enemy” som en vis man en gång sade, lite så.

Motverka DDoS och liknande attacker med Cloudflare och liknande tjänster

Ett populärt sätt att motverka detta som jag hört talas om men ännu inte haft möjligheten att implementera och testa själv är tjänster som Cloudflare som ska sätta upp en form av ”skyddsnät” framför din hemsida ut mot Internet som är tränad att känna igen- och kunna blockera dåligt beteende innan det når din faktiska hemsida och dess server.

Har hört många tala väldigt gott om det och att det ibland tillochmed talats om att vara typ ett av de- om inte det- bästa sättet att faktiskt skydda sig mot DDoS och liknande otrevligheter.

Förebygg framtida DDoS-attacker genom HTTP Access logganalys och IP-blockering

Alternativet brukar annars vara att man typ får gräva ned sig i loggfilerna och försöka identifiera IP-adresser som beter sig märkligt i HTTP Accessloggarna för att sen placera en IP-block för den typen av besökare i serverns brandvägg där hemsidan är hostad.

Men detta är också oftast något som upptäcks isf. och görs i efterhand vilket då brukar innebära att det är ”för sent” och skada redan kan ha skett.

När jag grävde i våra PHP-loggfiler för en plattformsbaserad hemsida så märkte vi att där genererades väldigt stora PHP loggfiler p.g.a. t ex. att PHP-version uppdaterats och vissa kodbitar för vissa tredjepartsmoduler osv. kanske inte var helt 100% anpassade vilket ledde till ofantligt många PHP notice osv. vilket kladdade ned hela PHP loggfilen och bidrog till enorma filstorlekar.

Det gick tillochmed så långt att filstorleken överskridit vad programmet jag brukar använda: TextPad – som jag btw varmt kan rekommendera för dig som arbetar i Windows miljö! – Klarade av att hantera, så hela datorn nästan hängde sig eller tog oändligt lång tid för att öppna filerna.

Splitta stora textfiler till flera mindre för att kunna öppna dem

Jag brukar samarbeta med erfarna utvecklare som stött på liknande problem tidigare och de tipsade mig då om GSplit och File Splitter tjänster/programvara, som är då designade att ta större textfiler, och dela upp dem i flera mindre textfiler.

När jag Googlade på det hittade jag även en StackOverflow tråd om hur man kunde åstadkomma detta med Git likaså.

Så istället för att ha en Loggfil på kanske 5 GB (ja det har hänt), så kunde man Splitta upp den i 5 filer om 1 GB per styck istället.

Vilket då underlättade i sin tur för TextPad att faktiskt klara av att öppna loggfilen.

Ett bra tips! För alla er som någon gång stött på liknande problem, där ni behövt ladda ned från FTP loggfilerna för att felsöka och analysera trafik eller felmeddelande för en hemsida och råkat ut för så stora filer att ni knappt kunnat öppna dem.

Kör ni via terminalen vilket många webbutvecklare kanske gör (om de har access) så kanske detta inte är ett lika stort problem, då det brukar finnas kraftfullare hanteringsmetoder via SSH och terminalkommando, jämfört med t ex. Windows OS GUI.

Men det är inte alltid man faktiskt har access till SSH och kanske måste undersöka loggfiler (om man ens har access till dessa) och då kanske man blir tvingad att använda t ex. FileZilla FTP klient för att ladda ned för att sen kunna undersöka och analysera i en vanlig texteditor på sin dator.

av ·0 kommentarer

Naivitet kan vara farligt. Medan ”only the paranoid survives”.

Lite halvt skämt o sido.

Detta inlägg syftar till att presentera en tankeställare för något som kan förekomma i en webbutvecklares vardag.

I min arbetsdag händer det att t ex. XML Sitemaps eller XML produktfeed filer kan bli korrupta.

Ibland händer detta p.g.a. att generering blivit avbruten mitt i p.g.a. överbelastning av sidan som skötte genereringen eller annat.

När detta händer och de vanliga fixen inte duger (prova köra om generering) kanske man vill försöka validera XML filen via något typ av verktyg.

Tänk bara efter INNAN du ev. laddar upp underlag som inkluderar känsligt material (t ex. hela produktkatalogen för en E-handelssida med samtliga inköpspriser) till en tredjeparts ”gratis-verktygs” hemsida.

Denna tanke har slagit mig ett antal gånger när jag varit i behov av validering men hindrat mig själv p.g.a. just denna anledning.

Risken är för stor för att ignorera.

Oftast har jag fått hitta lösningar på annat håll.

Jag säger inte nödvändigtvis att samtliga XML validatorer online som erbjuds gratis är suspekta, men det är också svårt att veta vad de gör med de uppladdade filerna, oavsett vad de säger.

Jag föredrar att vara lite skeptisk här. Säkra före det osäkra och så.

Vem vet, det kanske är obefogat, men det är inte en risk jag är villig att ta när jag bär det slutgiltiga ansvaret för vad som händer som följd av mina handlingar.

Det är lite som när man tar körkort, och de uppmuntrar att man som förare ska kunna väja för samtliga faror man kan förutse (och även dem man kanske inte förutser).

av ·0 kommentarer

Snubblade över en cool funktion i Google Inspector igår när jag satt och ville kolla upp vilket typsnitt Inleed.se använde, då jag tyckte deras typografi var väldigt stilren och lättläst.

CSS filtrering Google inspector

Har tidigare missat denna funktion, filter-sökfältet är ganska diskret i Google Inspector.

Men så sjukt smidigt att kunna söka upp valfritt CSS-attribut man är intresserad av och letar efter istället för att slippa scrolla igenom alla CSS regler för ett specifikt HTML element på en hemsida.

Bra tips för dig som också sitter mycket och jobbar i Google Inspector och leker med CSS i realtid i webbläsaren via verktyget.

av ·0 kommentarer

Jag behövde nyss en Vanilla JavaScript funktion som kontrollerar om ett regex existerar i en array ELLER en sträng.

Efter att ha sökt runt på Google och kollat diverse StackOverflow svar hittade jag inget som tyckte passade mina behov, så det blev att bygga/koda det jag behövde själv.

En kombination av en tidigare kontroll jag använt för att kontrollera om en variabel är array eller inte, kombinerat tillsammans med regex.test funktion i Vanilla JavaScript och en for-loop, se nedan:

/**
 * Super useful function to loop through an array to check vs RegEx if value of array slot match to regex (if array contains a string), if it is, return true, if not false, can also check string match, two-in-one combo
 * @param arrOrStr  - array or str with value(s) to loop through for regex match
 * @param regex     - regex to match array slot values against
 * 
 * @return          - true or false depending if match or not
*/
function regExCheckArrayOrStrMatch(arrOrStr, regex) {

  if(Array.isArray(arrOrStr)) {
    //console.log("in array match value");
    for(var i = 0; i < arrOrStr.length; i++) {
      if(regex.test(arrOrStr[i])) {
        return true;
      }
    }
    return false;
  }else {
    //console.log("in string match value");
    return regex.test(arrOrStr);
  }
}

Jag gillar hur simpel funktionen blev, och från vårt testande verkade den funka hur bra som helst.

Jag publicerade koden på min GitHub: Trekka12 , då jag tänker där säkert kan finnas ett värde för fler att använda denna typ av funktionalitet för sina webbprojekt.

Notera att denna går alldeles utmärkt att använda likaså för ens projekt som Custom Functions i Google Sheets – då även dessa använder sig av JavaScript.

Vissa kanske har en preferens för foreach av olika anledningar istället för vanlig for-loop, och det hade säkert gått bra att skriva om den till det likaså.