AIVD hackathon

[DJMaze]

Blijkbaar houdt de AIVD een hackathon.
Voor wie het interessant vindt https://www.aivdhackathon.nl/

spoiler: logo repeats

tegen de stroom in

[ Voor 9% gewijzigd door DJMaze op 02-01-2017 21:30 ]

[hellum]

Base64

[tinustate]

Nu maar hopen dat ze niet je cv uploaden naar tijdelijk bestand in https://www.aivdhackathon.nl/temp/ en vervolgens verplaatsen naar https://www.aivdhackathon.nl/uploads/ ...

Iemand zin om bestandsnamen te raden in bovenstaande directories?

Hier nog een aantal andere aanwezige directories:
https://www.aivdhackathon.nl/plugins/
https://www.aivdhackathon.nl/pages/
https://www.aivdhackathon.nl/custom/
https://www.aivdhackathon.nl/library/
https://www.aivdhackathon.nl/.htpasswd/

[Boudewijn]

Mwa wie zegt dat de inhoud van die directories ook niet altijd forbidden is? Als je dat altijd terugkrijgt, ongeacht of het bestand bestaat lijkt me daar niet zoveel mis mee.

En ja alleen als dat zo is, anders niet . Interessant.

[Firefly III]

-

[ Voor 100% gewijzigd door Firefly III op 21-10-2019 09:50 . Reden: Leeg ivm privacy ]

[tinustate]

aivdhackathon.nl geeft 200 bij niet bestaand:
https://www.aivdhackathon.nl/test

waarschijnlijk 403 bij geen index allowed:
https://www.aivdhackathon.nl/themes/

bestand in 403 geeft 200:
https://www.aivdhackathon...ndors/normalize-3.0.1.css

Het is dus niet allemaal standaard daar...

Een bestand in /uploads/ kan inderdaad beveiligd maar misschien ook niet. Dat weet je alleen als bestandsnaam weet, dus raden.

Interessante vraag is waarom cv's mogelijk in een publieke folder staan, een mogelijke aanwezige beveiliging daar is zeker niet beter dan in een niet publieke folder.

Overigens bied standaard htpasswd geen protectie tegen brute force e.d. (alleen via extra programma's, maar of ze die gebruiken?). Allerlei dingen om toch eens over na te denken.

Een super afgestelde firewall/software gebruiken ze in ieder geval niet anders was ik allang geblokkeerd, of misschien hebben ze dat expres niet gedaan

Ook een interessante vraag is waarom de gevonden directories bestaan, als ze niks doen en niet publiekelijk gebruikt worden (waar het op lijkt), is dat alleen een beveiliginsrisico.

[ Voor 32% gewijzigd door tinustate op 03-01-2017 14:59 ]

[irundaia]

Heeft iemand al de voorwaarden gelezen? Vooral van de laatste zin wordt ik semi-bang:

Deelname aan de Hackathon betekent dat je naam om veiligheidsredenen in ons systeem
wordt nageslagen.

Hoezo veiligheids redenen? Krijgt iedereen die snugger genoeg is om een code uit een plaatje te vissen dan automagisch een rood vlaggetje?

[FrankHe]

tinustate schreef op dinsdag 3 januari 2017 @ 14:43:
aivdhackathon.nl geeft 200 bij niet bestaand:
https://www.aivdhackathon.nl/test

...

Inderdaad een bizar slechte 404 handling op die site. Je zou bijna denken dat ze het met opzet gedaan hebben. Ik heb geen zin om verder rond te prikken op die site. Over tot de orde van de dag.

[Whatson]

irundaia schreef op dinsdag 3 januari 2017 @ 16:01:
Heeft iemand al de voorwaarden gelezen? Vooral van de laatste zin wordt ik semi-bang:


[...]


Hoezo veiligheids redenen? Krijgt iedereen die snugger genoeg is om een code uit een plaatje te vissen dan automagisch een rood vlaggetje?

Nee, denk dat ze checken of je niet voorkomt in hun systemen voordat ze je binnen laten op hun kantoor

[Boudewijn]

irundaia schreef op dinsdag 3 januari 2017 @ 16:01:
Heeft iemand al de voorwaarden gelezen? Vooral van de laatste zin wordt ik semi-bang:


[...]


Hoezo veiligheids redenen? Krijgt iedereen die snugger genoeg is om een code uit een plaatje te vissen dan automagisch een rood vlaggetje?

Je hoeft er toch niet aan mee te doen? Ik denk dat ze gewoon even willen weten wie er op hun feestje komen en of dat geen extremisten zijn oid.

Een beetje prikken op die website lijkt me wel mooi, ik denk dat ik ook maar eens in ga sturen.

[Firefly III]

-

[ Voor 100% gewijzigd door Firefly III op 21-10-2019 09:50 . Reden: Leeg ivm privacy ]

[DJMaze]

Als je eventjes had gekeken bij hvmp.nl dan begrijp je wel waarom het zo is
Blijkbaar hebben ze alleen PHP programmeurs en verder totaal geen essentiële experts/kennis in huis.
Of is "PHP programmeur" opeens een magisch woord waarbij iedereen denkt "die kan kan/weet echt alles"?
Tot nu toe heb ik persoonlijk alleen maar ervaring in zulke gevallen als "wat is het budget van jullie bedrijf waarin ik de bezem er door mag halen?"

Een eigen servertje bij BIT BV heeft dan wel het predicaat ISO/IEC 27001 maar als je dan een brakke website er op zet maakt dat niet uit.

Maar goed, ik ben volgens velen gestoord, en mijn code onleesbaar omdat het dingen doet in 1 regel i.p.v. 40.

[Boudewijn]

Mwa ik vind loc vaak eigenlijk minder relevant dan leesbaarheid en onderhoudbaarheid, als we het over general purpose doeleinden hebben. Bij embedded, exploits en challenges ligt het anders ja.

Voor een website/shellscript/desktopprogramma heb ik liever iets leesbaars, de compiler doet vaak die laatste slag redelijk goed voor je .

[FrankHe]

"PHP ontwikkelaar" staat niet per definitie gelijk aan "full stack web ontwikkelaar met verstand van high traffic sites en SEO". De manier van 404 afhandeling zegt mij al genoeg over competenties van de sitebouwer.

Bij een hackathon challenge is quick en dirty prototyping natuurlijk toegestaan. Maar haal het niet in je hoofd om die code daarna in productie te nemen.

Leesbaarheid en onderhoudbaarheid maken het leven echt een stuk gemakkelijker. Ook het begrip documenteren wordt door ontwikkelaars vaak verkeerd opgevat. Documentatie schrijf je in eerste instantie voor jezelf zodat je over twee weken of twee maanden na vandaag nog terug kunt halen wat je ook alweer gebouwd had. Een bijkomend voordeel van documenten is dat anderen er misschien ook nog iets aan kunnen hebben.

Meest extreme gevallen zijn de verschillende projecten waar ik op dit moment op werk. Compleet puinruimen zonder enige overdracht een geen enkel woord in een document. Navraag bij voorgaande programmeur leverde meteen de quote van het jaar op: "Mijn code documenteert zichzelf."

Maar ik dwaal nu volgens mij een beetje af.

[Boudewijn]

Ff heel flauw, maar is de AIVD een PHP ontwikkelbedrijf, al dan niet in full stack? Ik denk dat ze iets heel anders zoeken dan een average PHPer.
Die website is denk ik gewoon uitbesteed aan een bedrijfje, ik zou er dan ook niet al teveel aandacht aan geven.

Wie gaat zich inschrijven?

[BarôZZa]

FrankHe schreef op dinsdag 3 januari 2017 @ 17:45:
"PHP ontwikkelaar" staat niet per definitie gelijk aan "full stack web ontwikkelaar met verstand van high traffic sites en SEO". De manier van 404 afhandeling zegt mij al genoeg over competenties van de sitebouwer.

Bij een hackathon challenge is quick en dirty prototyping natuurlijk toegestaan. Maar haal het niet in je hoofd om die code daarna in productie te nemen.

Leesbaarheid en onderhoudbaarheid maken het leven echt een stuk gemakkelijker. Ook het begrip documenteren wordt door ontwikkelaars vaak verkeerd opgevat. Documentatie schrijf je in eerste instantie voor jezelf zodat je over twee weken of twee maanden na vandaag nog terug kunt halen wat je ook alweer gebouwd had. Een bijkomend voordeel van documenten is dat anderen er misschien ook nog iets aan kunnen hebben.

Meest extreme gevallen zijn de verschillende projecten waar ik op dit moment op werk. Compleet puinruimen zonder enige overdracht een geen enkel woord in een document. Navraag bij voorgaande programmeur leverde meteen de quote van het jaar op: "Mijn code documenteert zichzelf."

Maar ik dwaal nu volgens mij een beetje af.

Hij heeft min of meer gelijk. Goede code heeft heel heel weinig documentatie nodig. Documentatie schrijf je in eerste instantie niet. Als je niet meer snapt wat je code doet, dan heb je brakke code geschreven en had je beter daar je tijd aan kunnen besteden. Met korte functies en duidelijke functienamen zijn veel belangrijker.

Als iets wel niet storend is, dan zijn het geheel overbodige comments in code. Nederlandse of krom-Engelse volzinnen die langer zijn dan de code eronder. Documentatie buiten de code is meestal nog erger omdat die zelden up to date blijft.

En als laatste: niemand leest je documentatie.

[DJMaze]

BarôZZa schreef op dinsdag 3 januari 2017 @ 19:34:
Als iets wel niet storend is, dan zijn het geheel overbodige comments in code.

Wat dacht je dan van functies met 20+ parameters?
Bij meer dan 4 moet ik al verdomde goed opletten welke ik aanpas.

[Wild Chocolate]

Boudewijn schreef op dinsdag 3 januari 2017 @ 18:06:
(...)
Wie gaat zich inschrijven?

Dat kan ik je wel vertellen, maar dan moet ik je vermoorden

[ Voor 19% gewijzigd door Wild Chocolate op 03-01-2017 20:55 ]

[tinustate]

Boudewijn schreef op dinsdag 3 januari 2017 @ 18:06:
Ff heel flauw, maar is de AIVD een PHP ontwikkelbedrijf, al dan niet in full stack? Ik denk dat ze iets heel anders zoeken dan een average PHPer.
Die website is denk ik gewoon uitbesteed aan een bedrijfje, ik zou er dan ook niet al teveel aandacht aan geven.

Een overheidsorganisatie moet voldoen aan vele eisen met betrekking tot privacy en beveiliging wanneer ze een site online zetten. Als dat niet het geval is mag je hun daar zeker op aanspreken.
Want waarom zouden bedrijven zich door een hoop bochten moeten wringen terwijl een overheidsorganisatie goedkoop een bedrijfje inhuurt en privacy en security schijnbaar mag vergeten.
Bovendien is dit niet zomaar een informatie site, het bevat een formulier waar bezoekers zeer privacy gevoelige informatie invullen.

Veiligheid zou toch voorop moeten staan bij aivd, die ons moet beschermen.
Ook zou privacy van gebruikers voorop moeten staan bij een overheidsorganisatie.
Kosten voor privacy en security mogen niet, zeker niet mij de overheid, een besparingspost zijn.

[ Voor 255% gewijzigd door tinustate op 04-01-2017 09:46 ]

[FrankHe]

BarôZZa schreef op dinsdag 3 januari 2017 @ 19:34:
[...]

Hij heeft min of meer gelijk. Goede code heeft heel heel weinig documentatie nodig. Documentatie schrijf je in eerste instantie niet. Als je niet meer snapt wat je code doet, dan heb je brakke code geschreven en had je beter daar je tijd aan kunnen besteden. Met korte functies en duidelijke functienamen zijn veel belangrijker.

Als iets wel niet storend is, dan zijn het geheel overbodige comments in code. Nederlandse of krom-Engelse volzinnen die langer zijn dan de code eronder. Documentatie buiten de code is meestal nog erger omdat die zelden up to date blijft.

En als laatste: niemand leest je documentatie.

Wanneer je ervan uitgaat dat een developer haar / zijn werk goed heeft gedaan, de boel netjes heeft opgebouwd en coding standards (meer dan) een beetje heeft gevolgd. Dan ben ik het met je eens dat de daadwerkelijke code toe kan met 'zichzelf' en inline commentaar doorgaans niet heel veel toevoegt.

Maar helaas, daarom noem ik het ook puinruimen, zijn er projecten waarbij niet volgens 'de regels' is gewerkt. Dan gaat het allemaal ineens een stuk meer tijd kosten om erachter te komen waardoor het komt dat een systeem niet meer optimaal wil functioneren. Dan is een stukje oorspronkelijke projectdocumentatie best handig om te hebben. Het kan helpen om te beredeneren wat de oorspronkelijke bedoeling van een systeem is geweest op het moment dat het gebouwd werd. Als de server error log uitpuilt dan weet je wel hoe laat het is.

Mocht iemand de opdracht krijgen om de 404 handeling van een specifieke website te optimaliseren zodat die daadwerkelijk HTTP status code 404 teruggeeft in plaats van 200? Dan mag je hopen dat dit is te repareren middels een enkele kleine aanpassing en je niet op tachtig plaatsen code moet gaan zitten aanpassen. Uiteindelijk is het de klant die betaalt voor de tijd die het kost om de rommel van vorige ontwikkelaars weer recht te breien.

[FrankHe]

DJMaze schreef op dinsdag 3 januari 2017 @ 20:44:
[...]

Wat dacht je dan van functies met 20+ parameters?
Bij meer dan 4 moet ik al verdomde goed opletten welke ik aanpas.

Wanneer een functie zoveel parameters nodig heeft dan denk ik dat de code niet helemaal OO(P) is. Bouw in die class dan een paar functies erbij waarmee je eerst wat configuratiinstellingen zet voordat je de grote 'afvuur functie' aantikt.

Dat gezegd hebbende, een jaar of twee geleden werd ik gevraagd om een plug-in te repareren die een kalender genereerde aan de hand van een opgegeven range. Dat was zo'n monster functie met mixed type parameters en andere ongein erin. Heb toen om al die onzin heen een overwrite gebouwd, scheelde mij en mijn klant een hoop tijd en dus geld. Die kalender werkt nog steeds.