beveiliging van webstie

fsasfsas · 31 aug 2017

Dag

Ik ben een website aan het maken en op die website komen ook een contactformulier, een login en een search mogelijkheid. Ik heb inmiddels heel veel over de beveiliging daarvan gelezen maar ik vind het lastig om een beetje recente informatie te krijgen omdat sommige posts inmiddels behoorlijk gedateerd zijn.

Ik voer gebruikersgegevens (verkregen met POST) in de MySQL database in met prepared statements. Ik laat info die verkregen is door een of andere input alleen naar scherm schrijven via htmlspecialchars zoals hieronder staat. (in de code staan niet alle regels maar ik heb de mijns inziens belangrijke hieronder neergezet)

het invoegen van user input in database:

Code:

$sql = "INSERT INTO news_items (title, summary, image, text, newsdatetime) VALUES (?, ?, ?, ?, ?)"; 
/*...*/
$title = $_POST['title']; /* geen escaping hier want prepared statement */
/*...*/
mysqli_stmt_bind_param($stmt, "sssss", $title, $summary, $text, $image, $newsdatetime);
/*---*/
mysqli_stmt_execute($stmt);

het uitprinten van in database opgeslagen user input;

Code:

/*...*/
         while ($row = mysqli_fetch_array($result)) {  
            $titles[] = $row['title'];  
/*...*/
   foreach ($titles as $title): 
   echo htmlspecialchars($title, ENT_QUOTES, 'UTF-8'); 
   echo "<br>";
   endforeach;

zover ik weet, ben ik hiermee beveiligd tegen de meest voor de hand liggende SQL injections en XXS. Maar.... ik weet er te weinig van. Is de site nog vulnerable ergens voor?

groetjes, Anjo

Aar · 31 aug 2017

Ik weet niet hoe de rest van je site werkt, maar dit is een handige cheatsheet: https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

fsasfsas · 31 aug 2017

PHP4U zei:
Ik weet niet hoe de rest van je site werkt, maar dit is een handige cheatsheet: https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

ja, die had ik gezien maar daar staat dit boven:
DRAFT CHEATSHEET - THIS IS STILL A WORK IN PROGRESS OR OUT OF DATE

los daarvan weet ik niet goed hoe ik het toe moet passen, vandaar mijn vraag.

groetjes, Anjo

Aar · 31 aug 2017

Opsich kunnen security patches niet verouderd raken. Dus deze cheatsheet is zeker een mooie leidraad.

En WAT weet je niet toe te passen?

fsasfsas · 31 aug 2017

PHP4U zei:
Opsich kunnen security patches niet verouderd raken. Dus deze cheatsheet is zeker een mooie leidraad.

Die cheat sheet maakt bv gebruik van mysql en niet mysqli.

PHP4U zei:
En WAT weet je niet toe te passen?

Ik weet gewoon te weinig van het geheel en daardoor begrijp is sommige stukken van de cheat sheet niet. Daarom hoop ik op mijn vraag antwoord te krijgen in de trant van "dit en dit vormt ook nog een risico". Ik gebruik dus alleen maar prepared statements en escape outpu alles wat (via de database) uit een user-input komt maar ik trof meerdere posts aan die wisten te melden dat dat niet genoeg was. Maar ik kan nergens vinden wat er niet genoeg is en wat ik nog meer zou moeten doen. Temeer omdat veel posts veiligheidsissues bespreken op basis van mysql ipv mysqli.
Het wordt geen bank-account maar er zullen wel logins komen dus in zoverre wil ik de site zo veilig mogelijk maken. En het cheat-sheet en andere posts die ik gelezen heb doen me vermoeden dat alleen prepared statements en escapen i niet afdoende is maar ik weet gewoon niet op welke plekken ik nog meer zou moeten doen omdat ik niet voldoende thuis ben in de materie. Misschien is dat het probleem maar.... het is me nog niet gelukt er voldoende in thuis te raken, ondanks dat ik er inmiddels erg veel over gelezen heb. Kortom: is prepared statements en escaping voldoende of niet?

groetjes, Anjo

Aar · 31 aug 2017

Voor een query wel, hoewel je 'prepared statements' OF 'escaping' bedoelt. Maar ik neem aan dat je hele applicatie nog meer doet dan dàt alleen.

Ikzelf gebruik escaping icm MySQLi in mijn scripts.

Aar · 31 aug 2017

fsasfsas zei:
Die cheat sheet maakt bv gebruik van mysql en niet mysqli.

Ik zie toch echt de MySQLi functies?

fsasfsas · 31 aug 2017

PHP4U zei:
Ik zie toch echt de MySQLi functies?

excuus. In de code wel. even verderop weer niet

PHP comes with many built-in functions, such as addslashes, mysql_escape_string and mysql_real_escape_string

maar mijn reactie was wellicht te snel. in dat stuk staat ook dat ze er uit gaan. Maar mijn opmerking over dat ik de diverse posts (waaronder deze) eenvoudigweg niet goed genoeg begrijp blijft wel staan...
Ik weet gewoon niet wat ik nog meer zou moeten doen behalve prepared statements en escapen, omdat ik redelijk veel in dergelijke posts gewoon nog niet begrijp.

groetjes, Anjo

Aar · 31 aug 2017

Een paas basispunten:

- Veiligheid bij uploads
- Formulieren beveiligen tegen CSRF
- Je inlog goed beveiligen.
- XXS tegengaan
- Bij sterke voorkeur SSL gebruiken.

Die wikipagina vind ik toch best wel duidelijk, als ik eerlijk mag zeggen.

Maar veel concreets kan ik niks zeggen als ik niet weet wat voor applicatie je bouwt.

fsasfsas · 31 aug 2017

PHP4U zei:
Een paas basispunten:

- Veiligheid bij uploads
- Formulieren beveiligen tegen CSRF
- Je inlog goed beveiligen.
- XXS tegengaan
- Bij sterke voorkeur SSL gebruiken.

ik maak geen uploades van files mogelijk.
Ik heb een CSRF stukje gezien in de cheat cheet. Zal ik doornemen.
Hoe kan ik een inlog goed beveiligen?
XXS tegengaan is toch met escapen? Ik snap dat een framework beter is, zodat je er geen eentje vergeet...
SSL wordt gebruikt. Dat wil zeggen, er is een certrificaat.

PHP4U zei:
Die wikipagina vind ik toch best wel duidelijk, als ik eerlijk mag zeggen.

voor jou wel, maar voor een leek niet echt. Ik weet soms niet of het schieten is met een kanon op een mug. Dat kwam ook in een van de posts die ik zag naar voren. Daar werd geadviseerd om gewoon te blijven escapen als het geen grote website is en geen framework te gaan gebruiken.

PHP4U zei:
Maar veel concreets kan ik niks zeggen als ik niet weet wat voor applicatie je bouwt.

Dat snap ik. het is ook niet mijn bedoeling het helemaal bij jou of iemand anders neer te leggen. maar omdat ik er zo weinig van weet, is het lastig doelgericht iets te vragen.
Ik snap best dat het nooit 100% dichtgetimmerd kan zijn maar om alvast de zich vervelende "script kiddies" tegen te gaan zijn dingen zoals prepared statements en escapen een must, heb ik begrepen. Om de ingewikkeldere dingen tegen te gaan, zal ik er gewoon meer van moeten weten om de diverse posts te begrijpen (laat staan wat ze adviseren te implementeren).

Zo adviseert dat cheat sheet om === te gebruiken ipv ==
Is dat werkelijk overal nodig? Of alleen op de plekken waar het gaat om user input?

groetjes, Anjo

kenikavanbis · 31 aug 2017

A je hebt een hosting : dan zullen die veel voor jou doen die je niet onmiddelijk merkt.

B je hebt een eigen server: dan is het al een beetje complexer en dan maak je best niet je website kenbaar.

Met wat ik zien veilig NEE maar ik zien niet het volledige plaatje en dat maakt dat ik geen juist antwoord kan geven.

is het geautoriseert personeel
zijn de mensen die erop moeten werken betrouwbaar
zijn logins veilig

is de server beveiligd is de document root beveiligd
dan kunnen de computers waar de mensen het ingeven niet veilig zijn.

Je kan ook goedkopen servers gebruiken die nog eens je email adressen verkopen .
Je hebt dan nog slechtere servers waar men ook nog je wachtwoorden verkoopt(van je gebruikers).(van gratis of te goedkoop kan je niks verwachten)

Aar · 31 aug 2017

kenikavanbis zei:
A je hebt een hosting : dan zullen die veel voor jou doen die je niet onmiddelijk merkt.

Ik heb nog geen enkele hosting gezien die de websites klanten onderhoudt qua veiligheid. Dus ik vraag me af waar je dit vandaan haalt?
Er is een verschil tussen beveiliging van een web-applicatie en een server.

De klant is verantwoordelijk voor een veilige site, en de hostingpartij is verantwoordelijk voor een veilige omgeving voor de site.

bron · 31 aug 2017

Allereerst is een website nooit de volle 100% veilig!
Dat gezegd hebbende kan je heel simpel toch al veel aan beveiliging doen.

Gebruik je een cms, blog of andere applicatie met een beheer backend?
Zorg dat deze en de uitbreidingen up-to-date zijn.
Wijzig indien mogelijk de mapnaam van de beheer backend.
Gebruik nergens de gebruikersnaam admin of beheerder ofzo.

Gebruik verschillende sterke wachtwoorden voor:
control panel (provider), website backend, database user, FTP user, website smtp user.

Permissies van mappen 755, van bestanden 444, tenzij het niet anders kan.
Als je een schrijfbaar bestand nodig hebt, probeer dan in volgorde: 644, 664, 666.

Zet in mappen die geen index.html of index.php hebben een bestand "index.html" met hierin alleen de tekst 

Zorg dat bezoekers nooit bij een php bestand kunnen komen waar de opdracht phpinfo() in staat.

Het bestand robots.txt is interessant voor bezoekers. Je kan dit gewoon weglaten.

Maak altijd een Page Not Found pagina "404.php" en zet deze in www.example.nl/404.php

Gebruik https! Steeds meer providers bieden dit standaard in het pakket of tegen een laag tarief.

Belangrijk!
Zet de onderstaande code in een bestand www.example.nl/.htaccess

Code:

# page not found
ErrorDocument 404 http://www.example.nl/404.php

# block access to cgi,perl,python files
<FilesMatch ".(cgi|pl|py)">
Deny from all
</FilesMatch>

# block perl bots
SetEnvIfNoCase User-Agent libwww-perl bad_bots
order deny,allow
deny from env=bad_bots

RewriteEngine On

# uncomment next 2 lines if you use https
#RewriteCond %{HTTPS} !=on
#RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# remove directory listing
Options -Indexes

# IF the URI contains http:
RewriteCond %{QUERY_STRING} http\: [OR]
# OR if the URI contains [ or ]
RewriteCond %{QUERY_STRING} \[ [OR]
RewriteCond %{QUERY_STRING} \] [OR]
# OR if the URI contains <script>
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# OR if the script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# OR if any script is trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
# OR if the URI contains UNION
RewriteCond %{QUERY_STRING} UNION [OR]
# OR if the URI contains double slash
RewriteCond %{QUERY_STRING} // [OR]
# OR the request contains /proc/self/environ (LFI hack)
RewriteCond %{QUERY_STRING} proc\/self\/environ [OR]
# OR if the URI contains asterisk
RewriteCond %{QUERY_STRING} \*
# THEN deny the request 403
RewriteRule ^.*$ - [F,L]

# no advertising what you are running
ServerSignature Off

Suc6 met je beveiliging. Have fun.

Aar · 31 aug 2017

En om de noodzaak van veiligheid bij file-uploads even te benadrukken:
https://tweakers.net/nieuws/129023/...evens-van-forumleden-scholieren-punt-com.html

Het bestand robots.txt is interessant voor bezoekers. Je kan dit gewoon weglaten.

Niet mee eens, dit bestand wordt gebruikt door spiders die zo weten wat ze moeten indexeren.
Het is de noodzaak dat elk script waar iemand niet tot bevoegd is netjes beveiligd is.

bron · 31 aug 2017

RE: ...robots.txt... Niet mee eens, dit bestand wordt gebruikt door spiders die zo weten wat ze moeten indexeren.
Stel dat ik een mapje DOC op de server heb staan (noot: heb ik niet ivm security) dan weet een zoekmachine niet dat dit mapje er is want er is nergens een verwijzing naar dit mapje. Zelfs al zou er een verwijzing zijn dan wordt er niets geïndexeerd omdat er in dit mapje een dummy index.html staat, zie boven. Daarentegen als je in een robots.txt aan iedereen vertelt dat er een mapje DOC is die niet geïndexeerd mag worden dan is dit zeer interessant voor hackers!

Wil je eventueel toch vertellen wat er wel geïndexeerd moet worden gebruik dan een sitemap.xml

(edit) Google Search Console ziet graag een robots.txt bestand. Geef deze dan de inhoud

Code:

User-agent: * 
Disallow:

fsasfsas · 31 aug 2017

Dag allemaal

dank jullie wel voor het meedenken.

Ik gebruik geen bekende applicatie. ik ben bekend met dergelijke dingen en het gebrek aan veiligheid dat er soms mee gemoeid is als je niet de moeite neemt er even wat aan te doen. Ik heb verschillende malen zen en opencart (open source webwinkels) geïnstalleerd voor bekenden en toen veel over veiligheid met betrekking tot die dingen gelezen dus ik ben in principe bekend met de relatief eenvoudige dingen zoals het verwijderen van de instaleerdir en niet gebruik maken van de standaard benamingen voor allerlei zaken.
Een website van scratch bouwen is evenwel redelijk nieuw voor mij. Ik heb als provider DataCT en volgens mij zijn zij redelijk fel in het beveiligen van dingen. Niet duur maar zeker niet de goedkoopste. Ik ben niet bang dat zij voor een niet-veilige omgeving zullen zorgen. Maar hoe veilig zij het ook maken, dan nog steeds kan mijn website zelf zo lek zijn als een mandje.

De permissies zo strak mogelijk zetten zal ik zeker gaan doen. Een dummy index heb ik al staan in elke dir waar niemand iets te zoeken heeft. De 404 heb ik nog niet aangemaakt en zal ik zeker gaan doen. Ook de .htacces files heb ik (nog) niet aangepast. Ga ik ook doen.

Ik snap dat ik het niet helemaal dicht kan timmeren. Maar de meest voor de hand liggende gaten wil ik wel graag dicht maken. Zodat ik in ieder geval de "script kiddies" kan tegenhouden. Ik hoef niet meteen een huis dat beveiligd is als bankkluis, maar de deur afsluiten als je weggaat is toch wel zo handig. In die laatste categorie zoek ik het nu. Ik wil niet hemel en aarde bewegen om het kleinste gaatje dicht te maken maar wil wel graag de "voor de hand liggende" maatregelen nemen. En dat was voor mij prepared statements en escaping. inmiddels zijn daar wat andere tips bij gekomen.

Nogmaals dank voor jullie hulp!

groetjes, Anjo

Aar · 31 aug 2017

bron zei:
RE: ...robots.txt... Niet mee eens, dit bestand wordt gebruikt door spiders die zo weten wat ze moeten indexeren.
Stel dat ik een mapje DOC op de server heb staan (noot: heb ik niet ivm security) dan weet een zoekmachine niet dat dit mapje er is want er is nergens een verwijzing naar dit mapje. Zelfs al zou er een verwijzing zijn dan wordt er niets geïndexeerd omdat er in dit mapje een dummy index.html staat, zie boven. Daarentegen als je in een robots.txt aan iedereen vertelt dat er een mapje DOC is die niet geïndexeerd mag worden dan is dit zeer interessant voor hackers!

Wil je eventueel toch vertellen wat er wel geïndexeerd moet worden gebruik dan een sitemap.xml

(edit) Google Search Console ziet graag een robots.txt bestand. Geef deze dan de inhoud

Code:

User-agent: * Disallow:

En wat hebben hackers eraan als ze weten dat er een map is wat /DOC heet, terwijl er documenten in staan waarbij ze niet weten wat voor documenten, en welke bestandsnamen die hebben? Je kan nooit alle beveiligde locaties afschermen, als ze toegang erin maar wel goed is ingesteld.

bron · 31 aug 2017

Maar hoe veilig zij het ook maken, dan nog steeds kan mijn website zelf zo lek zijn als een mandje

Je slaat de spijker op z'n kop

De permissies zo strak mogelijk zetten zal ik zeker gaan doen. Een dummy index heb ik al staan in elke dir waar niemand iets te zoeken heeft. De 404 heb ik nog niet aangemaakt en zal ik zeker gaan doen. Ook de .htacces files heb ik (nog) niet aangepast. Ga ik ook doen.
Ik snap dat ik het niet helemaal dicht kan timmeren. Maar de meest voor de hand liggende gaten wil ik wel graag dicht maken.

Als je de .htaccess code uit bericht 13 toevoegt aan jouw .htaccess dan kom je een heel eind.

Ik hoef niet meteen een huis dat beveiligd is als bankkluis, maar de deur afsluiten als je weggaat is toch wel zo handig.

Een mooie vergelijking! Iemand die naar binnen wilt gooit een baksteen door het raam...

Ik wil niet hemel en aarde bewegen om het kleinste gaatje dicht te maken

Tja, het lukte een hacker ook om bij Visa in te breken... lijkt mij dat zij de beveiliging helemaal hadden dichtgespijkerd

En wat hebben hackers eraan als ze weten dat er een map is wat /DOC heet

@php4u. Mapje /doc was maar een voorbeeld! Er zijn helaas veel plugins die onveilig zijn door hun onveilige mapjes. Ik moet er niet aan denken dat de betaalmodule die ik in PrestaShop heb gezet onveilig zou zijn, bijvoorbeeld omdat er een mapje /examples in zit.
Ter afronding, vroeger waren de bots "dom" en ging het alleen om pure info websites. Toendertijd was robots.txt handig. Nu vind ik het persoonlijk echt overbodig en niets meer toevoegen omdat de bots van tegenwoordig "intelligent" zijn.

fsasfsas · 31 aug 2017

Dag allemaal

Ik ben zoetjesaan bezig met de tips te implementeren die ik hier gekregen heb en met zelf struinen...
Zo werd me van alle kanten Content Security Policy aangeraden. Ik heb de header daarvoor er in gezet en kreeg netjes inderdaad een heleboel blokkades. Allemaal opgeruimd, op eentje na. Dit is een blokkade van een onderdeel van de jquery: deze <script src="jquery/jquery-1.11.2.min.js"></script>

Ik heb ook naar een recentere versie gelinkt (en de link toegestaan binnen CSP) maar dat blijft dezelfde blokkade geven:

Content Security Policy: De instellingen van de pagina blokkeerden het laden van een bron op self (‘script-src https://www.jiangbaocollege.com’). Source: onfocusin attribute on DIV element.

Er zit vast een inline code in een van de onderdelen daar en inline code sta ik niet toe. Juist om XSS tegen te gaan. Echter: het zit op een onderdeel dat ik niet gebruik. Dat veronderstel ik tenminste want ik kan nergens op die pagina iets vinden dat mist of niet werkt. Ik heb daarom de neiging om mijn schouders er over op te halen. dan blokkeert ie maar iets wat ik vooralsnog toch niet gebruik. Er zit geen onfocusin op deze pagina.
Maar wellicht heb ik het in de toekomst wel nodig. Ik heb nu de ...min.js in gebruik. Deze staat letterlijk op de schijf in een subdir. Is het een idee om niet de minified maar de "originele" te downloaden en het inline deel in een externe file te zetten zodat CSP niet meer mekkert? Of is dat niet mogelijk of gewoon een hele domme uitspraak?

kenikavanbis · 31 aug 2017

PHP4U zei:
Ik heb nog geen enkele hosting gezien die de websites klanten onderhoudt qua veiligheid. Dus ik vraag me af waar je dit vandaan haalt?
Er is een verschil tussen beveiliging van een web-applicatie en een server.

De klant is verantwoordelijk voor een veilige site, en de hostingpartij is verantwoordelijk voor een veilige omgeving voor de site.

een hosting heeft een firewall en zijn er de hele dag mee bezet . in het ander geval heb je een eigen server en vps of een eigen server en moet je zelf meer doen.

@bron ik heb iets niet gezien zoals information underscore shema
ps binnen kort is er ook availe bilety en sec urity my sql

@fsasfsas bedankt voor je vraag ik heb ook nog enkel leuke stukken gezien .

beveiliging van webstie

Gebruiker

Inventaris

Gebruiker

Inventaris

Gebruiker

Inventaris

Inventaris

Gebruiker

Inventaris

Gebruiker

Terugkerende gebruiker

Inventaris

Moderator

Inventaris

Moderator

Gebruiker

Inventaris

Moderator

Gebruiker

Terugkerende gebruiker

Wij waarderen jouw privacy