hoe bescherm ik een id in de url?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Java Ontwikkelaar

Opdrachtbeschrijving Het scrumteam houdt zich bezig met boeiend en zichtbaar werk waarin allerlei kanten van de IT aan bod komen zoals gebruikersinteractie, belastingdienst java ontwikkelstraat, databases en koppelvlakken. Dit team ontwikkelt verschillende applicaties voor Dienstverlening waaronder GID(Generiek Informaten Desktop). Dit is een applicatie die de medewerkers van de Belastingtelefoon gebruiken voor het beantwoorden van vragen. Tevens werkt het team aan de ontwikkeling van bestaande en nieuwe formulieren voor verschillende portalen (Douane, Zakelijke en Burger) en diverse generieke voorzieningen.Performance en security zijn vanzelfsprekend uitermate belangrijke aspecten. In het team wordt bovendien veel aandacht besteed aan kwaliteit, onder andere door middel van

Bekijk vacature »

Jack Maessen

Jack Maessen

23/12/2019 20:31:47
Quote Anchor link
Voor een simpel mailinglist maak ik gebruik van flat-file (.txt) bestanden om de gegevens in op te slaan.
De naam van het textbestand, (met daarin de gegevens zoals Naam en Email) wordt gecreeerd met de id en .txt erachter. Dus zoiets als:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
id-15878547698.txt

Elke inschrijver krijgt een uitschrijflink mee die natuurlijk voor iedereen uniek is. die uitschrijflink bevat de id.
Ik gebruik overigens voor elke id base64_encode zodat ie niet direct voor het oog logisch lijkt.
Als een gebruiker op de uitschrijflink klikt, wordt de url string zoiets als:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
http://mijndomein.com/unsubsribe.php?id=id-aWQtMjAxOTEyMjMNDUyMTQ%3D&email=amNtZy5tYWVzc2VuQGdtYWlsLmNvbQ%3D%3D


Voor uit te schrijven ziet de code er zo uit:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
    $id
= $_GET['id'];
    $email = $_GET['email'];
    // decode the id and email string
    $id_decode = base64_decode($id);
    $email_decode = base64_decode($email);
    if( isset($id_decode) ) {    
                
        $filename = 'subscribers/'.$id_decode.'.txt';    
        // delete subscribers entry
        if(file_exists($filename)) {
            unlink($filename);    
            echo '<div class="alert alert-success"><b>'.$email_decode.'</b> is successfully removed from our mailinglist!</div>';        
        }

        else {
            echo '<div class="alert alert-danger">Email not found or you already have unsubscribed from our mailinglist!</div>';
        }        
    }

    ?>

Zoals je ziet: de id wordt eerst decoded en het txt bestand met de naam van de id wordt unlinked. De inschrijver is verwijderd.

Mijn zorgen: Als je een inschrijver was en je hebt uitgeschreven, dan weet je hoe de url eruitziet met de id erin. Zou je dan ook nog weten dat die id gekoppeld is aan een textbestand dat unlinked wordt bij uitschrijven, dan zou je er een bot op los kunnen laten op potentiele id's te raden en als die bot toevallig een id te pakken heeft die ook nog bestaat, dan wordt een willekeurige gebruiker dus uitgeschreven zonder dat ie het zelf heeft gedaan.

Mijn vraag: hoe kan ik dit beter beveiligen?
Gewijzigd op 23/12/2019 20:34:54 door Jack Maessen
 
PHP hulp

PHP hulp

28/02/2020 18:56:19
 
Adoptive Solution

Adoptive Solution

23/12/2019 20:50:26
 
- Ariën -
Beheerder

- Ariën -

23/12/2019 20:53:20
Quote Anchor link
Ik hoop ook dat het txt-bestand buiten de webroot staat.
 
Jack Maessen

Jack Maessen

23/12/2019 21:12:00
Quote Anchor link
Een encryptie kan, maar dat verandert de zaak toch niet? Ook op de encryptie hash kun je een robot loslaten. Als ie een hash genereert die met decryptie werkelijk tot een reeel bestand leidt, heb je hetzelfde probleem...

Toevoeging op 23/12/2019 21:24:51:

@Ariën
De tekstbestanden staan gewoon in een subfolder maar ik heb dit in mijn .htaccess staan:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<Files ~ "\.txt$">
    Order allow,deny
    Deny from all
</Files>

je kunt ze niet via de url inzien
Gewijzigd op 23/12/2019 21:25:58 door Jack Maessen
 
- Ariën -
Beheerder

- Ariën -

23/12/2019 21:27:24
Quote Anchor link
Brute-force detectie bouwen?
 
Jack Maessen

Jack Maessen

23/12/2019 21:30:41
Quote Anchor link
ik ben het met je eens dat txt bestanden met prive info beter buiten de webroot kunnen staan. In mijn geval kan ik ook alle data die in de .txt bestanden staat encrypten. Dan is het wat veiliger.
Gewijzigd op 23/12/2019 21:32:16 door Jack Maessen
 
Adoptive Solution

Adoptive Solution

23/12/2019 21:34:37
Quote Anchor link
Als ik de url uit het voorbeeld base64 decode, krijg ik dit :

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
id-20191223

LM

Email = jcmg.maessen@gmail.com


Encryptie is geen hash. Hoeveel robots je erop loslaat, zonder sleutel zal je niets kunnen decrypten.
 
Jack Maessen

Jack Maessen

23/12/2019 21:40:15
Quote Anchor link
@Adoptive Solution
ja dat klopt. Ik bedenk me net dat het idd beter is de data te encrypten ipv te encoden. Als je weet dat het een base64 is, kun je hem snel terugherleiden. Dan ben je idd snel achter de naam en email. Dus ik ga de data encrypten in de url.
Overigens bedenk ik me net: ik geef elk file een unique id mee en zend die als token mee in de url. Bij uitschrijven vergelijk ik de id met het bijbehoredn token. Als die iet bij mekaar horen, wordt er niet ge-unlinked.
Quote:
Encryptie is geen hash...

Dus met encryptie alleen ben ik veilig genoeg?
Gewijzigd op 23/12/2019 21:42:46 door Jack Maessen
 
Frank Nietbelangrijk

Frank Nietbelangrijk

23/12/2019 21:43:59
Quote Anchor link
Jack Maessen op 23/12/2019 21:30:41:
ik ben het met je eens dat txt bestanden met prive info beter buiten de webroot kunnen staan. In mijn geval kan ik ook alle data die in de .txt bestanden staat encrypten. Dan is het wat veiliger.



Klinkt een beetje als ik laat de portieren van mijn auto van het slot maar zorg wel dat de auto een start onderbreker heeft.

Ze zijn dan al in de auto. enkel nog de code van de startonderbreker en voila..

Overigens kun je eventueel een .htaccess bestandje in de directory zetten met de tekst "Deny from all" als je Apache gebruikt. Wel even testen of het werkt!

Toevoeging op 23/12/2019 21:50:13:

>> Dus met encryptie alleen ben ik veilig genoeg?

Alleen indien je een goede encrypt methode gebruikt en de sleutel goed ver weg opbergt. Dus niet in de webroot bewaren ;-)
 
- Ariën -
Beheerder

- Ariën -

23/12/2019 21:58:30
Quote Anchor link
En dan ga je over naar Nginx, en opeens werkt je .htaccess misschien opeens niet meer?
Wat is er mis met het buiten de webroot opslaan? Of ondersteunt je hosting dat niet? Dat zou ik dat eens bij hun neerleggen.....
Gewijzigd op 23/12/2019 21:58:46 door - Ariën -
 
Frank Nietbelangrijk

Frank Nietbelangrijk

23/12/2019 21:58:39
Quote Anchor link
Misschien handig: https://stackoverflow.com/questions/16600708/how-do-you-encrypt-and-decrypt-a-php-string

Toevoeging op 23/12/2019 21:59:54:

Inderdaad buiten de webroot is beter. Maar ook daar kunnen anderen bij (denk aan de server beheerders) dus encrypten is geen slecht idee.
 
- Ariën -
Beheerder

- Ariën -

23/12/2019 23:47:13
Quote Anchor link
Frank Nietbelangrijk op 23/12/2019 21:58:39:
Inderdaad buiten de webroot is beter. Maar ook daar kunnen anderen bij (denk aan de server beheerders) dus encrypten is geen slecht idee.

En wat dacht je dan van inloggegevens van je database? :-P
Bij een webhosting teken je ervoor dat de data eigendom van jouw blijft, en dat hosting er zomaar niets in te zoeken heeft, tenzij er een goede reden is.

Als iemand zomaar in mijn data staat te neuzen, dan kan die een belletje van mijn advocaat verwachten. :-P
 
Frank Nietbelangrijk

Frank Nietbelangrijk

24/12/2019 00:15:25
Quote Anchor link
Ja klopt. En dan dus die encryptie sleutel. Zet die er ook maar gelijk bij. Toch is de data niet meer in één klap leesbaar en zonder sleutel al helemaal niet. Ook backups (van de database) bieden zonder die sleutel dan weinig relevants.

Ik zeg overigens niet dat je nu al je data in de database moet gaan encrypten. Absoluut niet. Maar als je nou mijnheer Bol zou heten dan zou ik er toch serieus over gaan nadenken om al die duizenden mailadressen eens door de blender te halen...
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.