Uppgiftsbanken

Uppgifter, övningar och laborationer i HTML, CSS, JavaScript, PHP, SQL för att du skall få öva dig i webbprogrammering och webbutveckling.

Kontinuerlig säkerhet

Ni ska använda olika verktyg för att hitta säkerhetsproblem i Microbloggen och lägga till dem i er CI kedja.

#Krav

  1. När ni löser fel som hittas med nedanstående verktyg och commitar koden som löser felen, skriv tydliga commit meddelanden som förklarar vilket fel ni löser.

    • I redovisningstexten ska ni förklara vilka fel ni hittade och löste.
  2. Använd SAST verktyget Bandit för att hitta möjliga säkerhetshål i Python koden och lös dem.

    • Lägg till det som ett beroende i requirements/test.txt, med fast version (bandit==<version>).
    • Kör Bandit på koden i mappen app. Vi behöver inte köra det mot övrig kod i repot.
    • Lägg till ett Make kommando som kör Bandit på er kod.
    • Lös de fel som hittas.
      • Avgör om de fel som hittas är false-positiv eller inte. Om det är en false-positive kan ni lägga till så felet ignoreras, förklara varför i en kommentar.
  3. Använd skanner verktyget Trivy för att hitta möjliga säkerhetshål.

    • Använd Trivys Docker image med en fast version, t.ex. aquasec/trivy:0.75.0, så att samma verktyg körs hos alla och i GitHub Actions.
    • Använda target:
      • image för att söka igenom er Microblog produktions image.
        • Bygg först er image lokalt, t.ex. med docker compose build prod, för att köra Trivy på den.
        • Kör med docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:<version> image --scanners vuln,secret,misconfig --no-progress --severity HIGH,CRITICAL --exit-code 1 <er docker image>.
          • Ersätt <er docker image> med namnet på er image, t.ex. microblog:prod.
      • fs för att söka igenom hela repo mappen.
        • Stå i ert repo och kör med docker run --rm -v "$(pwd)":/repo -w /repo aquasec/trivy:<version> fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --exit-code 1 --no-progress --skip-dirs .venv,venv,kubernetes .
        • Mappen kubernetes skippas. Den kommer först i kmom05 och innehåller manifest från guiderna, som Trivy annars klagar på.
    • Lägg till make kommando för båda target.
    • Lös felen som hittas, se Trivy hittar många fel.
  4. Använd Docker lint verktyget Dockle för att hitta möjliga säkerhetshål i er produktions image.

    • Lägg till make kommando som kör Dockle på er produktions image.
    • Lös de fel som hittas.
    • Kör det med en fast version (släpp inte latest, då kan ett nytt Dockle få bygget att gå sönder):
    docker run --rm -v /var/run/docker.sock:/var/run/docker.sock goodwithtech/dockle:v0.4.15 --exit-code 1 <er docker image>
    
- Dockle returnerar exit kod 0 även när den hittar fel om ni inte skickar med `--exit-code 1`. Utan det kan inte CI bli rött.
  1. Skapa ett nytt workflow i GitHub Actions som kör Bandit, Trivy och Dockle på samma sätt som beskrivet ovanför.
    • Ert nya workflow ska köras före era CD workflow och måste passera för att ni ska pusha er Docker image och driftsätta den. Låt publish workflow anropa det med uses: ./.github/workflows/<fil>.yml och needs, på samma sätt som test workflow.
    • Det finns en färdig dockle Action man kan använda men ni ska inte göra det. Den söker även er “base image”, vi vill inte det och jag har inte hittat något sätt att stänga av det. Kör istället som vanligt via docker.

#Tips

#Trivy hittar många fel

Trivy kommer hitta många fel i produktions imagen, mer än vad ni kan lösa genom att ändra någon enstaka rad. Det är meningen, det är så det ser ut i verkligheten när man inte uppdaterar. Felen kommer från två ställen:

  • Base imagen (FROM python:3.8-alpine). Python 3.8 och dess Alpine version är gamla. Byt till en nyare och använd en tag med fast version (Python version och Alpine version). Gör det i både Dockerfile_prod och Dockerfile_test så att ni testar på samma Python som ni kör i produktion. Samma gäller Python versionen som ert CI workflow använder (python-version i setup-python).
  • Python paketen i requirements/prod.txt. Flask och Werkzeug är för gamla. Uppgradera dem och de paket som hänger ihop med dem. Läs pip felmeddelandena och paketens ändringsloggar för att se vilka versioner som passar ihop. Sätt också fasta versioner på gunicorn och pymysql i requirements.txt.
    • Vill ni slippa leta versioner finns en testad lista i requirements/prod-upgrade.txt i Microblog-repot (synka er fork). Byt ut paketen i prod.txt mot dem. Listan ändrar inte koden, det som går sönder efter uppgraderingen rättar ni själva, och ni ska kunna förklara varför Trivy hittade de gamla versionerna.

Efter uppgraderingen går inte allt som förut:

  • Något som koden importerar från Werkzeug finns inte längre. Läs felmeddelandet och Werkzeugs ändringslogg.
  • Werkzeug 3 gör längre lösenords hashar (scrypt) än kolumnen password_hash rymmer. Enhetstesterna använder SQLite och märker inget, men registrering mot MySQL ger 500 Data too long. Testa därför alltid att registrera en användare och logga in mot den riktiga produktions imagen med docker compose up efter en uppgradering. Ni kan lösa det genom att välja hash metod, generate_password_hash(password, method="pbkdf2:sha256"), eller genom att göra kolumnen längre med en migration.

fs skanningen kommer också hitta att .devcontainer/Dockerfile inte har något USER. Dev containern startar som root men kör som användaren dev (se remoteUser i devcontainer.json), så det är inget fel för oss, och att lägga till USER i filen gör att ni tappar tillgången till Docker. Läs i Trivys dokumentation hur ni ignorerar en enskild finding och skriv en kommentar om varför.

#Dockle

Dockle kan rapportera DKL-DI-0004 (apk add utan --no-cache) på ett lager som kommer från python base imagen, trots att --no-cache används. Det är en false-positive. Ignorera just den, läs i Dockles README hur, och skriv en kommentar om varför. Ni kan lämna INFO raderna (content trust, HEALTHCHECK) som de är.

#Revision history

  • 2026-10-18: (C, aar) Genväg: testad lista med paketversioner i requirements/prod-upgrade.txt.
  • 2026-10-09: (B, aar) Fästa versioner, make kommandon, exit koder och tips för uppgraderingen som Trivy kräver.
  • 2023-11-17: (A, aar) Första versionen.

Document source.

Read more »

Microbloggen i Ansible

Ni ska nu skapa playbooks för att sätta upp alla delar av microbloggen; databasen, applikationen på två servrar och en load balancer. Databasen körs på samma VM som load balancern för att spara kostnader.

#Krav

Efter kraven finns lite hjälp för att lösa er Playbooks.

  1. Skapa en Ansible playbook för att starta en MySQL databas i en Docker container på en server. Den ska köra på host “database” (gruppen innehåller load balancer VM:en).
    • Installera docker
    • Starta en MySQL container.
    • OBS! datan ska ligga i en volym så att den inte raderas om containerns startas om. Om VM:en raderas försvinner volymen och datan.
    • Sätt en restart policy (unless-stopped) så att containern startar igen efter stop_instances.yml och start_instances.yml.
  2. Skapa en Ansible Playbook för att starta er Microblog container. Den ska köras på host “appserver”, alltså ska den köras på både appserver1 och appserver2.
    • Installera docker
    • Starta en Microblog container som kopplas till MySQL containern som körs på host database.
    • Sätt en restart policy (unless-stopped).
  3. Uppdatera Ansible playbook deploy_lb så att Nginx skickar requests till båda appservrarna. Nu skickas det bara till en. Uppdatera upstream app-hosts i load-balancer.conf.j2. Ni får inte hårdkoda servrarna. Skriv kod som gör det dynamiskt och funkar om vi lägger till flera servrar.

#Tips

I Ansible, i era playbooks använd host namnet database för installationen av databasen, appserver för era servrar med Microblog och loadbalancer för Nginx.

När ni stoppar och startar VM’s:arna startar inte Docker containrar som saknar restart policy om. Sätt en restart policy på containrarna i era playbooks.

Ni kan använda ansible-lint för att få tips på hur ni bör skriva er Ansible kod. Ni kan använda -x <list of rules> för att exkludera regler.

Tips Skapa en roll som bara installerar Docker. Den kan ni återanvända för appserver och database. Ansibles modul community.docker.docker_container kräver Python paketet docker på servern, installera apt paketet python3-docker tillsammans med docker.io.

#Database playbook

När ni startar MySQL containern kan ni inte använda hashade lösenord, MySQL klara inte av det. De måste vara i plain-text.

När ni startar containern skicka också med MYSQL_ROOT_PASSWORD=<password> som environment variabel, ni kommer använda det längre fram. MySQL kräver också att ni sätter databasens namn, användare och lösenord för användaren, se dokumentationen för mysql imagen. Lösenorden hamnar i klartext i er kod, så använd inte samma lösenord som ni använder någon annanstans.

Load balancer VM:en har bara 1 GB minne och delar det med Nginx, Docker och MySQL. MySQL 5.7 använder mycket minne som standard och första starten, när databasen skapas, kan få VM:en att sluta svara (SSH får timeout). Starta containern med flaggorna --performance-schema=off --innodb-buffer-pool-size=64M --max-connections=50 (som command till containern). Rollen 10-first-minutes lägger också till en swapfil av samma skäl. Första starten tar en stund, vänta tills MySQL går att logga in på med appens användare innan ni startar appen.

#Microblog playbook

När ni ska koppla Flask appen till databasen behöver ni IP addressen för databas servern, ni kan inte längre använda er av Dockers länkning för att de körs på två olika maskiner. Använd domännamnet ({{ domain_name }}) för databas hosten, det funkar både med den dynamiska inventoryn och med en hosts fil. {{ groups.database[0] }} finns bara efter att gather_instances har körts. Tips om ni inte lyckas koppla upp er mot database kan ni logga in på er VM och köra docker logs <microblog container namn> för att se loggen för docker containern.

#Load balancer playbook

Ni hittar loggfilerna för Nginx i /var/log/nginx. Om en konfig fil inte fungerar kan ni köra nginx -t för att validera den.

Certbot och HTTPS är redan gjort i rollen deploy_lb. Läs om certbot_staging nedanför.

#Certifikat och Let’s Encrypt

Load balancern får sitt HTTPS certifikat av Let’s Encrypt via certbot. Let’s Encrypt ger bara 5 riktiga certifikat per vecka för samma domän, och varje ny load balancer VM begär ett nytt. Bygger ni om miljön flera gånger tar certifikaten slut och då går det inte att få fler på en vecka.

Därför finns variabeln certbot_staging i ansible/group_vars/all.yml. Är den true (standard) begär certbot ett test-certifikat, som inte har någon gräns men som webbläsare och curl inte litar på. Är den false begär den ett riktigt. Bygg och testa med true. Sätt den till false en gång när allt funkar, då byts testcertifikatet ut mot ett riktigt. Ett riktigt certifikat ersätts aldrig. Ni behöver läsa koden i deploy_lb för att förstå hur det går till, den ska ni kunna förklara.

#Revision history

  • 2026-10-18: (C, aar) Minnestips för MySQL på load balancer VM:en.
  • 2026-10-09: (B, aar) Databasen körs på load balancer VM:en, restart policy, python3-docker, certbot staging.
  • 2025-11-14: (A, aar) Första versionen.

Document source.

Read more »

Vad är privat egentligen?

Du skall fundera och diskutera kring vilken information som klassas som privat samt argumentera varför just den informationen borde vara privat. Som utmaning, ställ er gärna i företagens skor och fundera på varför de “behöver” den informationen de frågar efter.

Du skall intervjua 2 personer, gärna med olika bakgrund samt redovisa frågor och svar. Dessa intervjuer ska sen sammanställas i en reflektionen som ska göras individuellt.

#Nice-to-have länkar

#Scenario

Företaget du jobbar på ska göra en webbplats med känslig information åt företaget Dbwebb AB. Du är en duktig webbprogrammerare redan men vad vet du om privat information och hur hanterar du den. För att vidga dina vyer och lära dig mer om privat information så intervjuar du 2 personer. Det är ditt jobb att ta reda på vad de tycker och kan om privat information. Du ska sammanställa åsikterna från de du intervjuar med dina åsikter i ett dokument, en Reflektion. Detta dokument ska vara underlag till en rapport om hur känslig information ska hanteras på webbplatsen. Uppdraget med rapporten vill gärna Dbwebb AB ha.

#Intervju

Du förbereder intervjuerna och du behöver minst ha med dessa frågor:

  • Vilken typ av information är privat?
    • Har du samma uppfattning som den du intervjuar?
  • Vad för information kan du hitta om varandra/dig/närstående på internet?
    • Är informationen frivilligt given eller inte?
    • Går det att hitta eventuellt läckta lösenord kopplade till deras mail? (Gör gärna Have I been pwned?)
  • Litar du på att företag håller din data “säker”? Finns det företag du litar mer/mindre på?
  • Den 1 oktober 2019 trädde den nya reviderade datalagringslagen i kraft (Sweclockers). Är detta rätt eller fel sätt att bekämpa brottslighet? Eller är det inte så enkelt som rätt eller fel?

Diskutera gärna lite med den du intervjuar. Innan du gör intervjuerna så tänker du igenom dina svar på frågorna för att ha något att jämföra med sen i Reflektionen. Intervjufrågor och svar lägger du i sin helhet i ett Appendix till Reflektionen. Appendixet bör bli ca 2-3 sidor långt.

Inled Appendixet med en kort beskrivning av personerna du intervjuar och diskuterar med, till exempel ålder, kön, yrke, relation till datorer och it-säkerhet eller liknande för att ge läsaren en uppfattning om vad det är för person. Därefter skriver du första frågan och under den redovisar du vad person 1 svarar, vad person 2 och så vidare. Appendixet ska alltså återspegla intervjun. Du ska redovisa vad de du intervjuar svarar. Svarar personerna “för kort” få du be dem utveckla eller förklara mer.

#Reflektion (självständig)

Skriv en reflektion där du tänker igenom över vad de du intervjuat tycker och vad du själv tycker/tänker. Kanske har du fått en annan syn på vilken information som ligger ute efter intervjuerna eller så hade du stenkoll på din data. Reflektionen ska användas som underlag till ett uppdrag som Dbwebb AB fått. Innehållet i Reflektionen hjälper Dbwebb AB att se om du och ditt företag är rätt för jobbet. Lycka till!

Följ kraven i reflektionen.

  • Reflektionen ska ha ett försättsblad med titel (Vad är privat egentligen?), datum och namn/studentakronym.
  • Reflektionen ska vara ca 1-2 sidor (exklusive försättsbladet, storlek 11 för brödtexten, 1 sida är ca 600 ord).
  • Texten kan skrivas på svenska eller engelska.
  • Använd stycken för att dela upp texten och försök att skriva det som en sammanhängande text.
  • Om intervjuerna har fått er att fundera kring hur du hanterar er data (både privat och som utvecklare), lyft gärna detta.
  • I slutet av reflektionen lägger du ett Appendix med intervjuerna. Låt Appendix starta på en ny sida.

Det finns en LaTeX mall tillgänglig här som du kan använda. Länken är till en read-only version, för att skapa er egna så trycker du “Menu” och sen “Copy Project”. Det går givetvis att använda valfritt program, så länge man uppfyller kraven ovan.

Inlämning

Spara din reflektion i pdf format och lämna in på Canvas.

Bedömning

Ditt dokument hanteras först av administratören på Dbwebb AB som plockar bort de reflektioner som inte följer kraven med försättsblad, antal sidor osv. Efter första granskningen av administratören så är det tekniska ledningsgruppen på Dbwebb AB som bedömer innehållet.

Har du fått ett G, så har ert företag fått uppdraget. Lycka till!

#Revision history

  • 2024-10-16: (F, grm) Intervju istället för diskussion HT24.
  • 2022-05-20: (E, grm) Komplettering HT22.
  • 2021-11-10: (D, grm) Komplettering HT21.
  • 2020-05-27: (C, nik) Uppdaterad med bland annat LaTeX mall
  • 2019-11-13: (B, nik) Fler frågor, tydligare struktur på reflektion.
  • 2019-08-07: (A, nik) Första utgåvan.

Document source.

Read more »

Category: kurs/itsec.

Bygg kort och kortlek i PHP och Symfony enligt MVC

Du skall skapa ett antal klasser i PHP. Dessa klasser skall du sedan använda i ett par webbsidor och visa upp att de fungerar. Tanken är att du bygger grunden till någon form av enklare kortspel med objektorienterade tekniker i ramverket Symfony.

Read more »

Category: kurs mvc.

Bygg en me-sida till mvc-kursen

Du skall sätta samman en webbplats som du kan använda som me-sida i kursen. I din me-sida gör du en presentation av kursen, dig själv och du publicerar dina redovisningsstexter.

Du lägger allt i ett Git-repo och när du är klar så publicerar du och taggar ditt repo på GitHub (eller GitLab).

Read more »

Category: php, kurs mvc.

Lager appen del 5

Vi ska i denna uppgiften använda oss av Web-API:s för att komma åt native-funktionalitet i våra fysiska mobila enheter. Vi använder en mobil enhets styrka och läggar till funktionalitet för GPS, kartor och kamera.

Read more »

Category: javascript.

Lager appen del 6

Vi avslutar vår Lager-app med en kundservice chatt.

Read more »

Category: javascript.

Yahtzee spelet del 2 - klasser

I denna uppgiften ska ni fortsätta med Yahtzee spelet ni började på i kmom02.

Read more »

Category: oopython.

Yahtzee spelet del 2 - Flask

I denna uppgiften ska ni binda ihop Yahtzee spelet så att ni får ett fungerade Yahtzee för en spelare.

Read more »

Category: oopython.

Fortsättning på Yahtzee spelet

I denna uppgiften ska ni binda ihop Yahtzee spelet så att ni får ett fungerade Yahtzee för en spelare.

Read more »

Category: oopython.