Sinds dit jaar heeft o.a. google een nieuwe ontwerp voor een standaard voor: SMTP Strict Transport Security. De beveiliging van SMTP is momenteel nog niet goed doordat bij het gebruikte STARTTLS het opzetten van een SMTP sessie tussen twee mailservers(MTA) en van een client(MUA) naar een mailserver(MTA) bijna altijd opportunistische encryptie(ongeldig of ongevalideerd certificaat) en/of onversleutelde verbindingen toelaat. Dit komt vooral vanwege de noodzakelijke compatibiliteit met andere mailservers(MTA) en misgeconfigreerde mail clienten(MUA). (Zorg ervoor dat je poort 587/submission met STARTTLS gebruikt en niet poort 25 voor e-mail verzending gebruikt). Wat betreft de communicatie tussen mailservers over poort 25 is de harde keuze is er alleen de keuze voor wel of geen e-mail uitwisselen als de verbinding alleen onveilig(bij geen STARTTLS ondersteuning) opgezet kan worden.

Er bestaat al enige jaren de HTTP Strict Transport Security header. Deze HTTP header wordt gezet na het opzetten van een veilige HTTPS connectie en zorgt ervoor de webbrowser voor een lange tijd onthoudt om alleen veilig verbindingen te maken met die website. Op die manier zal er bij terugkomst op de website nooit een downgrade van een veilige verbinding naar een onveilige verbinding kunnen plaatsvinden. De HTTP header wordt echter wel na een veilige HTTPS sessie gezet. Bij SMTP STARTTLS is dit niet mogelijk omdat de verbinding begint met een onveilige SMTP verbinding om te onderhandelen of dat encryptie gebruikt gaat worden. Nu maakt SMTP strict transport security gebruik van een TXT DNS record om het SMTP Strict Transport Security beleid te vinden op een subdomain _mta_sts.
Een mailserver die een e-mail naar een andere mailserver gaat versturen moet immer toch al via DNS het ip adres van de mailserver om mee te verbinden opzoeken. Maar omdat DNS onveilig is als er geen DNSsec gebruikt wordt moet dit DNS record weer gevalideerd worden met een JSON beleid over HTTPS. Want wanneer er geen DNSsec gebruikt op het domain moet nu het hele HTTPS protocol gebruikt gaan worden om de authenticiteit en integriteit van een SMTP Strict Transport Security DNS record te kunnen garenderen. Het SMTP Strict Transport Security lijkt me momenteel zonder DNSsec nog niet eenvoudig te implementeren wat het gebruik en de adoptie ervan voorlopig in de weg kan zitten. Wat jammer is want DNSsec en vooral DANE wordt nog steeds vaak niet ondersteund. Voorlopig blijft daarom e-mail verkeer tussen mail servers bijna altijd niet volledig veilig beveiligd.

Er is een nieuwe major versie van de populaire PHP taal uitgegeven. De major versie is van 5.x naar 7.0 gegaan als stabiele versie nummer.
De 6.x versie van PHP heeft wel bestaan maar er is nooit een stabiele, algemeen beschikbare versie van uitgegeven omdat het vooral gebruikt werd om mee te experimenteren met o.a. unicode ondersteuning (al sinds 2005). Enkele mogelijkheden zijn uiteindelijk aan PHP versie 5.3, 5.4, 5.5 en 5.6 is toegevoegd.
Nu wordt dus versie 7.0 uitgegeven. Een belangrijke vernieuwing is in PHP 7.0 is de mogelijkheid om return datatypes op te geven. Nieuwere versie’s van PHP bieden vaker strong typing mogelijkheden omdat strong typing o.a. sneller is. Ook zijn verschillende nieuwe operators aan PHP 7 toegevoegd waaronder: de null coalescing operator en de spaceship operator. Ook is het nu mogelijk net als Java en C# anonieme klasses aanmaken dit kan in PHP 7 met de new class keywords. Daarnaast bevat PHP 7.0 nu de random_bytes en random_int functies voor een cryptografische veilige pseudo random generator(in tegen stelling tot rand en mt_rand die niet cryptografische veilige zijn) en deze functies zijn niet afhankelijk van openssl(de openssl_random_pseudo_bytes functie).
Zie de lijst met nieuwe features van PHP 7.0.

Hallo webmasters, webdesigners en ontwikkelaars etc. Laten we het defacto eens worden, dat we de cookie permissie gegeven cookie, de naam CONSENT geven. Ja dat is de cookie die geplaatst wordt met als enige doel om te onthouden of je cookies mag plaatsen.
Als we afspreken de naam CONSENT te gebruiken dan bespaart dit mogelijk ellende bij iedereen die geïrriteerd wordt van al die cookie meldingen. Omdat als dit voor iedere site die mee doet gebruikt wordt het voor de gebruiker van het web mogelijk makkelijker wordt alleen deze cookies van alle cookies te beheren. Dit kan zeker handig zijn voor gebruikers die alle cookie willen gaan opschonen van behalve die CONSENT cookies zodat ze niet opnieuw toestemming moeten gaan geven waarvoor de gebruiker al toestemming gegeven heeft.

Oracle heeft de een nieuwe versie van Java uitgegeven.
Deze versie biedt mogelijke voor ontwikkelaars om Lambda expressie te gebruiken.
Dit kan bijvoorbeeld nuttig voor het maken van makkelijke multi core optimalisaties van Java implementaties van bepaalde code.
Verder is het in versie (1.)8.0 van Java nu mogelijk een functionele interface te schrijven.
Dit is een interface die code bevat. Zo kun je hiermee een (functionele/SAM)interface schrijven in Lamaba expressie die dus in de interface
al een mockup implementatie bevat. Ook qua beveiling is er wat verbeterd in Java (1.)8.0. Zo is nu standaard de TLS 1.2 implementatie van Java aangezet voor encryptie. Die was in Java(1.)7 standaard uit geschakeld en moest in de configuratie paneel van het Java handmatig aangezet worden. Met het gebruik van TLS1.1 en TLS1.2 of hoger ben je veilig van de BEAST aanval die werkt met TLS1.0 en een CBC AES encryptie algoritme om verkeer mogelijk te ontsleutelen.
Ook is nu de officiële versie van de netbeans 8.0 IDE uitgegeven na de release van Java 8.0 die o.a. de nieuwe Lamba expressies kent.

Om te controleren dat een systeem veilig is, is het aan te bevelen de integriteit van de belangrijkste bestanden op het systeem te controleren.
Hiermee kun je te weten komen of onverwachts bestanden gewijzigd zijn of nieuwe onbekende bestanden zijn toegevoegd.
Het is mogelijk hiervoor kant en klare oplossingen te gebruiken zoals AIDE, Tripwire of OSSEC.
Maar je kunt het ook zelf een bash script maken om controle van de integriteit van bestanden op systeem te controleren.
Om het onszelf makkelijker te maken schrijven we eerst een script die alle bestanden en hash waardes in een nieuw script automatisch vastlegt.
Hierdoor hoeven we niet handmatig de hash waardes van bestanden te gaan bijwerken. Wat ook een groot risico op het maken van fouten heeft als het veel bestanden zijn die handmatig de hash waardes van bijgewerkt moeten worden.
Het script opgeslagen als antitampercheck_generate.sh om hash waardes van bestanden in een nieuw script te genereren ziet er als volgt uit.

#!/bin/sh
# Write hashes of all files in a folder.
printhashesfolder() {
        if [ ! -d $1 ] ; then
                echo "Error: not a folder."
                exit 1
        fi

        foldersearchpath=$1'/*'
        for file in $foldersearchpath
        do
                if [ -f $file ] ; then
                      HASH=$(sha1sum $file | cut -d ' ' -f 1)
                      if [ "$HASH" != "" ]; then
                           echo 'checkhashsha1 "'$file'" "'$HASH'"' 1>> antitamperchecks.sh
                      fi
                fi
        done

        # add number of files check:
        NUMBERFILES=$(ls -1 $1 | wc -l)
        echo 'checknumberfiles "'$1'" "'$NUMBERFILES'"' 1>> antitamperchecks.sh
}

echo 'remove old script.'
sudo rm antitamperchecks.sh
echo 'creating new script.'
sudo touch antitamperchecks.sh
sudo chmod 700 antitamperchecks.sh
echo 'write basics functions in script.'
cat antitamperchecks_funtions.txt 1>> antitamperchecks.sh
echo 'writing new file hashes to script.'
printhashesfolder '/bin'
printhashesfolder '/usr/sbin'
printhashesfolder '/sbin'
printhashesfolder '/etc/ssh'

Dit script genereert van elke bestand in de map /bin, /usr/sbin, /sbin en /etc/ssh een nieuwe regel met de aanroep naar de checkhashsha1 functie met als parameter de sha1 checksum van het bestand. Verder schrijft het ook een regel bij elke map met de aanroep van checknumberfiles met als parameter hoeveel bestanden in de map stonden.
Vervolgens creëren we nog een tekst bestand genaamd antitamperchecks_functions.txt waarin de de volgende regels staan.

# Check and compare sha1 hash of a file.
checkhashsha1() {
        HASH=$(sha1sum $1 | cut -d ' ' -f 1)
        if [ "$HASH" != $2 ]
        then
                echo "Bad: $1 file. It's: $HASH and should be sha1: $2."
                MODIFYDATE=$(stat -c %y $1)
                echo "Last modify on: $MODIFYDATE"
        fi
}

# Check the number of files in a folder
checknumberfiles() {
        NUMBERFILESNOW=$(ls -1 $1 | wc -l)
        if [ "$NUMBERFILESNOW" != $2 ]
        then
                echo "There are new or deleted files in: $1."
        fi
}

# Selfcheck of sha1sum program with sha256sum.
SHA256BINSHA1=$(sha256sum /usr/bin/sha1sum | cut -d ' ' -f 1)
if [ "$SHA256BINSHA1" != "91b690492d585e70467f8cbafa4c30bf93dee13fcd31a4aba8deae663739ee93" ]; then
        echo 'Alert sha1sum changed! Environment cannot be trusted.';
        exit 1;
fi

Het bestand voegt nog de controle toe aan het script om het sha1sum programma dat de sha1 bestands hash berekent met een sha256 hash te controleren dat het hash programma zelf niet aangepast is.
Als laatste stap kunnen we nu ons script genaamd antitampercheck.sh genereeren door antitampercheck_generate.sh uit te voeren.
Het bestand antitampercheck.sh kan dan later uitgevoerd worden om te zien welke bestanden gewijzigd zijn sinds de laatste keer dat antitampercheck_generate.sh uitgevoerd is.
(beveilings aantekening: Letop dat de bash interpreter zelf ook nog aangepast kan worden het is misschien aan te raden de bash interpreter samen met checksum programma’s en de scripts offline veilig te bewaren.)

Er is een nieuwe minor versie van PHP uitgegeven.
Onder andere nieuw aan deze versie is dat het veilig password hashing nu eenvoudig gemaakt wordt door de functie password_hash etc. in de programmeer taal op te nemen. Voor PHP 5.3 en PHP 5.4 is er een classes beschikbaar genaamd password_compat om deze hashing functie’s te kunnen gebruiken zonder meteen PHP te moeten upgraden. De password_hash functie maakt standaard gebruik van het blowfish algoritme om hashes op te slaan. Blowfish is in tegenstelling tot de algemene md5/sha1/2 functie exponentieel lastiger bij het uitvoeren van meerdere rondes met het algoritme. Hiermee is het vertragen (key streching) tegen het snel kraken van de hashes steeds exponentieel lastiger bij toevoegen van een ronde. Ook heeft blowfish in tegenstelling tot de algemene hash functies bij meerdere rondes hogere vereiste werkgeheugen nodig waardoor het lastig is blowfish op geoptimaliseerde hardware te gebruiken.
Verder heeft PHP nu een ingebouwde opcacher. Een opacher zorgt ervoor dat een php bestand gecompileert direct opnieuw uit het geheugen uitgevoert kan worden. In PHP 5.5 is nu de Zend OPcache in PHP 5.5 opgenomen. Deze opcacher is iets sneller dan APC of xcache opcacher die al als PHP extensie beschikbaar zijn. Maar de Zend OPcache biedt geen extra API voor variabelen in het werkgeheugen op te staan. Om de ingebouwde zend opcacher in PHP 5.5 te gebruiken moet opcache.enable=On aan de PHP configuratie toegevoegd worden.
Verder maakt PHP 5.5 de beveiling iets gemakkelijker zo is nu bijvoorbeeld standaard de optie ENT_QUOTES in de functie htmlentities() gebruikt zodat htmlenties standaard cross site scripting veilige tekst teruggeeft. En in de regulaire expressie methodes is gaat de PREG_REPLACE_EVAL “e” nu in de ban.

Sinds een paar jaar is het mogelijk om AJAX webpagina’s te laten indexeren door googlebot. Google heeft de zoekrobot aangepast om javascript(officieel: ECMAScript) te begrijpen.
Hiervoor moet je website wel gebruik maken van een speciale url structuur. Er moet namelijk een haakje en een uitroepteken voor individuele ajax pagina’s binnen één echte pagina gebruikt worden.
Het haakje wordt normaal gebruikt om binnen een webpagina te springen maar sinds Firefox 3.6 is het mogelijk in javascript hierbij een onhashchange event af te vangen. Dit is belangrijk omdat je hiermee het terug navigeren van binnen de ajax pagina op orde kunt maken. Let wel op dat naast googlebot zijn er nog steeds zoek robots zijn die javascript / ajax url structuur niet begrijpen. Ik ben zelf wat aan het experimenteren met de ajax url structuur op mijn snippets website, vooral om te zien of de website nu ook gevonden kan worden in google op individuele ajax pagina gedeeltes.
Om voor zoekmachines de individuele pagina gedeelte te kunnen opnemen moet je ook de _escaped_fragment_ parameter implementeren naast de ajax manier van de pagina gedeelte laden. Met de _escaped_fragment_ parameter zul je de pagina op een traditionele manier laden de individuele pagina’s zodat die door de zoekmachine herkent kan worden. Meer informatie vindt je o.a. bij de webmasters help documentatie van google.

Het gebruik van _escaped_fragment_  wordt afgeraden en googlebot ondersteund het sinds 2008 niet meer. In plaats daarvan wordt de history api aanbevolen.

Laatst had ik het probleem dat een website fouten gaf o.a. dat het doctype van de pagina misvormt was.
Ook mijn gedefineerde content security policy had opeens alles op de pagina geblokkeerd. Terwijl het echt wel leek dat de gedefinieerde content security policy het laden wel zou moeten toelaten. Ik had vrij snel het vermoeden dat het om een tekst encoding probleem ging. Echter ik had het bestand toch opgeslagen als unicode ‘UTF-8’ tekst encoding en dit was ook de encoding waarop webserver ingesteld staat. Hoe kan het dan misgaan?
Na wat sniffen met wireshark bleek er voor het eerste tekens in de bronweergave van de webbrowser nog een paar tekens extra te staan die niet weergegeven waren.
Wat was het probleem? Ik had de broncode bestanden van de website opgeslagen als UTF-8 met notepad++ en niet aangeven dat ik géén Byte order mark tekens wilde.
Hierdoor zijn er in het begin van het php document nog voor de <?php tekens nog een paar Byte order mark(afgekort: BOM) tekens opgeslagen. En deze tekens werden dus direct naar de cliënt verstuurd als hexidecimaal waardes: 0xEF,0xBB,0xBF.
Ook de server http headers zijn door het toevoegen van de BOM tekens al verzonden waardoor de content security policy header die in php gedefinieerd was laten niet meer gaat omdat de http headers al verzonden zijn doordat de pagina inhoud al is verzonden doordat de BOM tekens pagina inhoud zijn.
Het is dus verstandig BOM tekens te vermijden in broncode bestanden van je server side programmeer talen als je geen problemen wilt. Het W3C dat de web standaarden definieert heeft er ook al eens iets over geschreven.

BASE is een in PHP geschreven webinterface voor het bekijken van Snort IDS alerts die naar een database geschreven zijn.
Echter is de gebruikers authenticatie wachtwoord opslag van BASE niet bepaalt zo veilig meer als de database gestolen wordt.
Wachtwoorden worden namelijk als md5 zonder salts in database opgeslagen. Het md5 hash algoritme is tegenwoordige met rainbow tables of online via opzoek website’s eenvoudig te op te zoeken of vrij snel met een videokaart te kraken. Tijd dus om het hash algoritme in BASE te vervangen door een betere, hier is hoe md5 vervangen wordt door het sha512 algoritme met prefix en suffix salts.

Eerst passen we het bestand /includes/base_auth.inc.php aan.
Regel 332 vervangen we door:

$hash = hash("sha512", ($this->prefixsalt . $passwd . $user . "BASEUserRole" . $this->suffixsalt));

Vervolgens vervangen we regel 354 in het hetzelfde bestand met:

$cryptpwd = hash("sha512", $this->prefixsalt . $password . $this->suffixsalt);

Dan gaan we terug naar het begin van het bestand voegen we de na “var $db;” op regel 34 de volgende regels toe, waarbij we voor de $prefixsalt en $suffixsalt variabelen we een willekeurige random stuk tekst kiezen als salts.

private $prefixsalt = "veryrandomstringhere";
private $suffixsalt = "yetanotherveryrandomstring";

Vervolgens passen we in de database het wachtwoord veld aan zodat het een langere hash kan opslaan. Dit doen we met een tijdelijk PHP script die ook meteen ook een nieuwe wachtwoordhash voor de gebruiker waarmee je aanmeld in de database van BASE update.

< ?php 
$adminusername = "admin"; // acidbase gebruiker.
$aminpassword = "lamepassword"; // (nieuw) gebruiker wachtwoord.

error_reporting(0);
include_once("/includes/base_auth.inc.php"); 
$baseuser = new BaseUser(); 
$hash = $baseuser->cryptpassword($aminpassword ); 
$dblink = mysql_connect($alert_host, $alert_user, $alert_password);
if (!$dblink) {
    die("database settings incorrect.");
}

mysql_db_select($alert_dbname);
$resupdfield = mysql_query("ALTER TABLE `base_users` CHANGE COLUMN `usr_pwd` `usr_pwd` VARCHAR(128) NOT NULL AFTER `usr_login`");
$resupduserpwd = mysql_query("UPDATE `base_users` SET `usr_pwd`= '".mysql_real_escape_string($hash)."' WHERE `usr_login` = '".mysql_real_escape_string($adminusername)."' LIMIT 1");
if ($resupduserpwd && $resupdfield) {
    echo "
AcidBASE gebruiker updaten succesvol.
\n
          Je kunt dit bestand nu verwijderen.
";
} else {
    echo "
AcidBASE gebruiker updaten mislukt.
";
}

Pas $adminusername en $aminpassword met de gegevens van de account waarmee je inlogt op acidbase. Sla vervolgden de code hierboven op als update_user.php in de hoofdmap van AcidBASE. Vervolgens ga je naar AcidBASE webinterface en roep je update_user.php aan. Als updaten succesvol is kun je het script verwijderen, je kunt nu inloggen op AcidBASE dat gebruik maakt van sha512 met prefix en suffix salt gehashte wachtwoorden.

Als je een foto van een digitale camera of scanner gaat vergroten of sterk verkleinen dan ken je dit probleem wel de afbeelding wordt minder scherp en de pixels worden opgetrokken tot blokjes bij sterke vergroting van een fotos. Echter Dani Lischinski van de Hebrew University is het gelukt de vorming van deze blokjes bij sterke vergroting van een foto, ook wel pixelated genoemd, sterk te verminderen. Hij doet dit door niet elke pixel op de zelfde manier te verplaatsen maar juist door vormen samen te stellen van enigszins overeenkomende kleuren van pixels. Op die manier is het mogelijk een sterk vergrote foto er scherper uit te laten zien. Natuurlijk als je geen foto’s maar plaatjes hebt kun je altijd perfecte kwaliteit bij het schalen ervan krijgen door een vector afbeelding (svg) te gebruiken.

open_basedir is een verouderde, niet volledig veilige configuratie optie om uitvoer van PHP script en toegang tot bestanden te beperken tot een bepaalde map. Echter is open_basedir niet volledig waterdicht omdat bepaalde features zoals de opgeslagen sessie’s in PHP buiten de open_basedir moeten werken.
Hier is hoe een PHP script toch bestanden uit een andere map kunt gebruiken. In een shared hosting omgeving waarin openbase_dir de enige beveiliging is, is dit dus als volgt te misbruiken.

ini_set("session.save_path", "/sessions/user2/");
putenv("TMPDIR=/sessions/user2/");
ini_set("session.save_path", "");
@session_start();

Mijn advies voor server administrators is om de webserver te “jailen”,
dit verkomt ook dat met andere scripttalen die onder de webserver process draaien misbruikt kunnen worden om hoster zijn server volledig te hacken.
Verder is het instellen van de juiste bestandspermissies belangrijk, het is ook belangrijk om het gebruik van symbolische bestands links uitschakelen.
Daarnaast kun je nog putenv en ini_set functies aan disabled_functions van php configuratie toevoegen om deze bekende manier van open_basedir restricties te misbruiken te blokkeren.

Standaardisatie in software versie nummers is er wel, maar wordt niet echt consistent toegepast.
De eindgebruiker wil niet weten welke versie nummer van software er gebruikt als het maar de laatste versie is.
Omdat eindgebruikers niet veel getallen wil onthouden en het niet makkelijk vinden om mee te werken gebruiken sommige software uitgevers daarom maar een naam voor iedere release. Maar er is nu ook een nieuwe trend om vaker het major nummer van het versie nummer te verhogen. Het goede is dus dat met het vaker verhogen van het major nummer makkelijk is voor eindgebruiker verandering bij te houden.
Maar het zorgt ook voor verwarring met software uitgevers die het traditionele manier van versie nummers gebruiken.
Maar wat is het traditionele manier een versie nummers geven eigenlijk? Ik zelf handteer een aantal vuistregels om te bepalen welke nieuw versie nummer een software release moet krijgen.
– Een versie nummer bestaat uit de volgende 4 getallen: major-, minor-, release-, build nummer.
Verder kan een woord toegevoegd worden dat de kwaliteit aangeeft, dit kan zijn: alpha, beta, rc. Wanneer het niet gebruikt wordt is het een stabiele final versie. Het build nummer mag voor de eindgebruiker weggelaten worden, omdat dit getal niks nuttig voor de eindgebruiker vertelt.
– Voor een nieuwe major nummer moet minstens 50% van de broncode ten opzichten van de vorige major release verandert zijn.
– Voor het verhogen van het minor nummer moet minstens 10% van de broncode ten opzichten van de vorige minor release verandert zijn. En er moet ten minstens 1 feature toegevoegd zijn.
– Voor een nieuwe release versie moet er ten minstens 1 bug opgelost.
– Een build nummer wordt verhoog iedere keer dat broncode gecompileerd wordt.
Welke vuistregels voor het toepast worden de niet traditionele snellere major releases, lijkt te zijn dat wat minor releases gedaan wordt nu als major release gepresenteerd wordt. Consistent en gestandaardiseerd is het nog niet.

Een nieuwe major release van Netbeans Integrated Development Environment uitgegeven.
Netbeans kan voornamelijk voor Java maar ook PHP en andere talen programmeer talen gebruikt worden.
Nieuw in Netbeans 7.0 is de ondersteuning voor Java (1.)7.0, dat de nieuwste versie van Java die nog ontwikkeling is.
Ook is er nu officiële ondersteuning voor PHPDoc en HTML5 voor web development. Voor web development is Netbeans best geschikt, samen met een installatie met xdebug voor PHP is het al mogelijk PHP script daadwerkelijk te debuggen vanuit Netbeans. Ook handig is het dat je een Oracle^® database of mysql database direct vanuit de IDE kunt bewerken.
Verder lijkt netbeans versie 7.0 nu iets sneller opstarten dan in 6.9.1. Maar de opstarttijd van netbeans en totdat die eidelijk klaar is met het openen van alle projecten is nog steeds veel langer dan even met notepad++ iets doen. Maargoed  netbeans is dan wel een prima IDE voor Java en PHP. Netbeans 7 is te downloaden vanaf: netbeans.org/downloads/

Een eenvoudige manier om je bezoeker te beschermen bij een geslaagde hack op je webapplicatie,
is door gebruik te maken van de nieuwe beveiligings features die nu in veel webbrowser komen.
Veel van deze features werken door speciale HTTP header opties te sturen. Een nuttige optie is bijvoorbeeld de X-FRAME-OPTIONS http header die aangeeft of een webpagina in een frame geladen mag worden.
Als je bijvoorbeeld wilt dat je PHP applicatie niet in een frame mag worden weergeven dan moet je dit voordat je html begint te versturen op die pagina de volgende regel opnemen.

header("X-FRAME-OPTIONS: DENY");

Een nog verder gaande beveilig optie is X-Content-Security-Policy HTTP header, die beperkt waar inhoud vandaan geladen mag worden.
Echter zijn er vrij weinig  webbrowser(chrome) die deze beveiligings feature al ondersteunen.
Als je bijvoorbeeld de volgende regel toevoegd mag inhoud (afbeeldingen, css, javascript bestanden enz.) alleen van hetzelfde domein komen.

header("X-Content-Security-Policy: allow 'self';");

Let wel op dat deze maatregelen slechts de impact van misbruikt beperken, als je een XSS probleem hebt is het echte probleem niet opgelost. Daarbij komt nog dat het voor een heleboel oudere webbrowser niet werkt. Maargoed, je bezoekers zouden ook geen Internet Explorer6 meer moeten gebruiken. Deze website heeft de beveiliging features in ieder geval wel al ingebouwd en IE6 gebruikers wordenwerden gewaarschuwd dat ze moesten upgraden naar een hogere versie van hun browser. Een manier om de Http headers te bekijken is door het programma Wireshark of bijv. de Firefox extensie’s als: HttpFox,  Live HTTP Headers of Firebug te gebruiken.
Het is ook nog mogelijk via HTTP headers de XSS(cross scripting) filter van Internet Explorer aan- en uit te zetten. Dit kan met:

header("X-XSS-Protection: 1; mode=block");

maar het is niet nodig deze header te gebruiken want de XSS filter staat standaard al aan.

Eerder had ik het al over 5 static sourcecode analyzers voor PHP scripts die je kunt gebruiken om je geschreven PHP code op beveiliging te testen. Het is daarnaast ook handig een tool te gebruiken om je eigen webapplicatie daadwerkelijk aan te vallen op een manier dat hackers en scriptkiddies ook kunnen. Dit geeft vaak ook een betere kijk op welke informatie over de interne werking van je webapplicatie je vrijgeeft.

Netsparker^®
Dit is mijn favorieten security audit tool. Een groot voordeel ten opzichten van andere producten is dat het probeert geen enkele false positive te geven, en dat doet het erg goed. Dat betekent dat als deze tool je webapplicatie gescant geeft en het aangeeft dat er een SQL injectie is er dan echt een SQL injectie is. Daarnaast heeft het ook wat praktische adviezen zoals bijvoorbeeld autocomplete=off toevoegen aan wachtwoord velden. Het nadeel van geen enkele false postive proberen te geven is wel dat mogelijke bepaalde beveiligingslekken niet gevonden kunnen worden omdat ze onzeker zijn. NetSparker vindt dus vooral de meest belangrijke beveiligingsproblemen. De “Community Edition” is alleen voor niet zakelijk gebruik. Een beperking is dat de instellingen niet gewijzigd kunnen worden.
website www.mavitunasecurity.comwww.netsparker.com

WebCruiser
Deze tool vindt soms wat unieke beveiligings problemen. Er zit ook een tool voor het fuzzy’en naar Cross site scripting beveilings problemen. WebCruiser is behoorlijk snel in vergelijking met de andere tools. Het bevat ook een tool waarmee een proof of concept gegeneerd/uitgevoerd kan worden van een gevonden beveiligingsprobleem. Hiermee kun je dus aantonen dat een beveiligingsprobleem in de webapplicatie dat getest wordt ook echt is. De gratis versie bevat reclame links.
website www.sec4app.comwww.janusec.com

WebSecurify
Deze tool vindt vooral veel beveiligingsproblemen maar het scannen duurt wel ook wat langer. Het doet allerlei extra tests die ik in andere producten nog niet ben tegen gekomen. Het nadeel van veel beveiligingsproblemen proberen op te sporen is naast dat het aanvallen even kan duren ook dat niet elke gevonden beveiligingsprobleem echt een beveiligingsprobleem hoeft te zijn. Het programma is iets minder overzichtelijk dan gebruikers interface van WebCruiser en Netsparker maar WebSecurify is volledig OpenSource en er is geen betaalde versie.
Daarnaast is WebSecurify de enige tool die veel fuzzying doet en daarmee de lastige beveilingsproblemen vindt.
website www.websecurify.com

Ik heb het spel FroggerReloaded 1.0.0 uitgegeven. Van deze frogger kloon spel moet je er niet veel verwachten, was eigenlijk een simpel schoolproject van een paar weken. Het spel heeft verschillende levels. Verder er is een level editor om zelf een levels aan het spel toe te voegen.
Ook worden levels voorvertoond zodra het level keuze scherm getoond wordt. En er is nog een highscore gesorteerd op snelste tijd dat frogger de overkant bereikt heeft.
Qua code zit toch aardig wat interessante dingen in verwerkt. Ook dingen die met performance te maken hebben.
Maar als gebruiker van het spel merk je daar niet veel van. Het spel is op het moment niet echt uitdagend, iets wat in een goed arcade spel wel moet. In het orginele frogger moest je verschillende kikkers meerdere keren dezelfde scherm laten oversteken en op een onbezet stukje plaatsen bovenaan.
In FroggerReloaded is 1keer de overkant bereiken voldoende. Maar omdat de kikker springt bij het lopen is het soms lastig. Download froggerreloaded

Static source code analyzers zijn tools die een programmeur helpen om bepaalde bekende beveiligingsfouten in code te vinden.
Een static source code analyzer kan handig zijn. Maar de meeste kunnen maar een beperkt deel van de fouten die een programmeur maakt vinden. Daarnaast kan een static sourcecode analyzer soms een valse beveiligslek als resultaat geven. Dus het houden van code reviews blijft belangrijk voor het garanderen van de veiligheid van een bepaalt stuk code. Maar code analyzer kan wel wat helpen.
De meeste PHP static sourcecode analyzers zijn ook in PHP geschreven, het voordeel daarvan is dat de veiligheid compleet met je server configuratie getest wordt.

Ik heb op het internet gezocht naar PHP sourcecode analyzers en heb deze interessante opensource producten gevonden.

RIPS:
Pas nieuw project, dit project won een tweede plek in de maand van PHP beveiliging 2010.
https://sourceforge.net/projects/rips-scanner/

PHP Security Scanner:
https://sourceforge.net/projects/securityscanner/

spike phpsecaudit:
https://sourceforge.net/projects/phpsecaudit/

PHP-sat:
Update: deze tool is niet meer beschikbaar.

Pixy
Update: dit java programma is ook niet meer beschikbaar.

Stel je wilt bent iets aan het tellen bij de ontwikkeling van je dynamische website.
Dan zijn er vaak twee manieren om dit te doen.

1. In PHP tellen bijvoorbeeld:

$numdownloads = mysql_num_rows(mysql_query("SELECT * FROM downloads));

2. in je SQL query tellen bijvoorbeeld:

$sqlnumdownloads =  mysql_fetch_array( mysql_query("SELECT COUNT(*) AS aantal FROM downloads) );
$numdownloads = mysql_fetch_result($sqlnumdownloads,0,'aantal');

Je kunt verwachten dat de 2e methode sneller is. Omdat niet eerst alle data opvraagt wordt en deze van de database server naar de webserver over gestuurt wordt. De netwerk verbinding vormt de grootste bottelneck. Maar wat als de database server en webserver dezelfde computer is? Dan is de ‘overdracht’ van de gegevens niet de bottleneck meer. Maar ook dan is het tellen in SQL vaak sneller dan in PHP. Dit omdat het PHP parser nog het probleem dat het een grotere bulk data moet verwerken omdat deze data niet door de simple SQL query geoptimaliseerd is. Sterker nog als je MyISAM voor opslag gebruikt zal het resultaat direct beschikbaar zijn omdat het al gedaan is door steeds het aantal verwijderen en toevoegen van records bij te houden. M.a.w. het loont qua performance het tellen in SQL te doen.

Na veel dingen in het CodeGreen spel te veranderen is er dan nu een nieuwe release van het spel gekomen. Het is eigenlijk niet gebruikelijk voor een game veel release te doen. Dus met deze update zijn veel dingen veranderd waarmee ik gelijk een hele hoop problemen van 1.0.1 probeer op te lossen. Het is dus niet een uitbreiding van het spel maar verbetering van alle problemen. Ten eerste wordt de highscore nu niet meer in een Access database opgeslagen. De access database was vrij groot, ook al zat er geen highscores in.  Daarom heb ik besloten gebruik te maken van de SQLLite database, die als publiek domein gelicenseerd. Dat is goed, want het combineert beter met opensource spel. Nog een voordeel van SQLlite is dat het lichter in geheugen gebruik is en veel sneller dan access. Verder is het probleem dat de muziek stop als een effect geluidje speelt nu opgelost. Maar ik besloten hier niet DirectSound voor te gaan gebruiken om geluid gelijktijdig te kunnen afslepen. In plaats daarvan heb ik een oplossing bedacht om extra geluidje te laten afspelen via een tweede process. Het is een beetje slordig maar hier vermij ik dat DirectSound en dus directX nodig is. Het voordeel van vermijden van Managed DirectX DirectSound is dat de gebruiker niet mee lastig gevallen wordt dat het directX nodig heeft, want dat is zeker 100mb aan bibliotheken. Dat is ook niet noodzakelijk want het spel gebruikt voornamelijk alleen GDI+ en heeft voor het teken en geen complexe 3d modelen nodig. Daarnaast blijft er zonder directX de mogelijkheid om codegreen op Mono onder linux of mac te draaien. Verder heb ik nog het logo op het hoofdscherm transparant gemaakt. Daarvoor moest ook de manier waarop de tekst naar beneden viel herschreven worden. Maar datzelfde effect is nu ook aan het optie scherm toegevoegd. CodeGreen 1.5 is nu te downloaden
Vooral voor mensen die het spel nog niet kennen een aanrader, om te leren hoe hacking simplistische werkt.
update: ik heb 1.5.1 uitgeven omdat een belangrijk dll’tje voor highscoren te laden ontbrak in de 1.5.0 release.

PHP6 is nu flink in ontwikkeling en het is waarschijnlijk niet lang meer voordat we de eerste php6 release gaan zien. Een ding waar ik blij mee ben is dat in PHP6 magic quotes extensie nu niet meer werkt.

Het probleem met magic quote’s was dat vele PHP programmeur dachten dat ze hun PHP script veilig konden overzetten op een andere hosting terwijl dat niet het geval was. Wat magic qoutes extensie voor PHP scripts namelijk doet is voor elke input via POST en GET variabele de aanhalingstekens en enkele aanhalingsteken escapen.

Dan is het niet mogelijk dat een bezoeker, een string variabel in je script probeert te verlaten en PHP code kan uitvoeren.
Echter gebeurt dit alleen als magic quote op je hosting aanstaat.
Het is dus ook belangrijk dat in de test omgeving en productie omgeving dezelfde instellingen voor magic quotes gebruikt want anders dan is dat vragen om beveiligingsproblemen. Zonder magic quote moet de programmeur zelf ervoor zorgen dat string variabel veilig wordt.

Dan is er ook nog het probleem met magic quote’s dat het de beveiling die de php programmeur wel gemaakt heeft kan opheffen.
Dit gebeurt als Magic Quotes  een slash met aanhalingsteken gaat escape en er dan een dubbele slash staat wat in feit betekent dat de slash ge-escaped wordt en niet het aanhalingsteken meer.

PHP magic quote heeft dus voor veel verwarring en dus beveiligingsproblemen gezorgd terwijl het juist een beveiligingsprobleem automatisch moest oplossen.
Een overzicht van wanneer een php script dus veilig is ziet er dan zo uit:

Een oplossing om een script toch onder zowel hosting met magic quotes aan en magic quote uit veilig te maken was door eerst te controleren of magic quotes aanstond.
Dit kan door de functie get_magic_quotes_gpc() te gebruiken. Echter moet je dan dus wel een aantal dingen dubbel schrijven, een routine waarbij het script niet escaped als magic quote aanstaan en een andere stuk code waarbij de script wel escaped als magic quotes uitstaat. Een slimmer manier om niet overal get_magic_quotes_gpc() te hoeven aanroepen is om een functie te schrijven die je steeds aanroept wanneer je ergens mogelijk moet escapen en in die functie te controleren of magic quotes aanstaat.
Indergeval, in de toekomstige php6 versie zal magic quotes standaard er niet meer zijn en zal de php programmeur dus altijd moeten escapen. Dat maakt het wel een stuk duidelijker.