Alternatief voor base64
Guido - op 06/01/2024 13:14:48:
PHP sessies zijn niet toegestaan binnen WP, daarvoor hebben ze "transients" bedacht.
Guido
Guido
LOL, Wordpress als PHP in het kwadraat! En laat me raden, als je niet met Wordpress wilt werken, dan gebruik je het toch niet?
Ik heb goddank geen verstand van Wordpress, het is mij te spaghetti, met hun aparte Codex alsof het de Bijbel is. De waarschijnlijke reden dat je niet direct eigen sessies (al dan niet in PHP) mag gebruiken is omdat Wordpress die liever voor zichzelf gebruikt en niet wil delen, of dat ze gewoon te eigenwijs zijn.
Hoe dan ook heeft het niets te maken met de vraag, namelijk een alternatief voor Base64. Je kunt ook gewoon Base63 gebruiken, of elke andere Base. Het is niet eens een vorm van encryptie, alleen een andere vorm van representatie.
En zoals Guido aangeeft, doet hij er ook helemaal niets mee, want de uitkomst wordt ook in Base64 opgeslagen in een 'transient' (wat het ook mag zijn), en vergeleken op de server. Wat de browser er dan mee moet? Misschien moet je toch ook eens duidelijker uitleggen wat je nu eigenlijk precies doet en wilt bereiken.
@Ozzie PHP:
Quote:
Als je inderdaad de uitkomst meestuurt in het formulier, dan is dat ongeveer hetzelfde alsof je je voordeur op slot draait en de sleutel onder de mat legt. :-)
Goed punt, ben inmiddels ook tot de conclusie gekomen dat dit erg makkelijk misbruikt kan worden.
Quote:
In het hidden input field van het formulier zou ik een random string opslaan. Die string sla je ook op in de database met daarbij een tweede veld waarin je de uitkomst opslaat. Als je het op deze manier doet, is de uitkomt op geen enkele manier te herleiden uit je hidden input field.
Ik maak nu pas een database entry aan nádat op verzenden is geklikt (om zo onnodige database entries te voorkomen). Volgens mij maakt het dan niet uit dat je een extra hidden string toevoegt aan het formulier, die is dan te onderscheppen en te wijzigen door kwaadwillenden. Ik moet een database entry aanmaken vóórdat op verzenden is geklikt.. toch? Maar goed, ik ga off-topic ;-)
Guido
Gewijzigd op 08/01/2024 22:03:07 door Guido -
Dat lijkt me wel ja. Daar sla je dan de random string in op met in het tweede veld de uitkomst van de som.
>> Volgens mij maakt het dan niet uit dat je een extra hidden string toevoegt aan het formulier, die is dan te onderscheppen en te wijzigen door kwaadwillenden.
Als iemand de random string wijzigt, dan komt deze niet meer voor in de database en neem je het formulier niet in behandeling. Maar kun je dit niet beter via sessie doen? HEb je al geprobeerd of je kunt werken met $_SESSION ?
Guido
Maar daarvoor zit waarschijnlijk Wordpress ook weer in de weg.
Al heeft MariaDB ook uuid() net als MySQL om UUID's te genereren.
De tijd heeft mij inmiddels ingehaald.
Ter info, dit was de situatie:
Quote:
Mijn formulier toont een willekeurige som captcha.
Ik voeg de uitkomst ook toe als hidden input.
Tijdens versturen wordt die uitkomst in database opgeslagen (dmv een WordPress "transient").
De invoer van invuller wordt vergeleken met uitkomst in database.
Daarna wordt de "transient" verwijderd uit database.
Doordat de "transient" niet meer bestaat, is de inzending niet bruikbaar voor een repeater bot die $_post hergebruikt.
(ik gebruik reeds de Post/Redirect/Get methode)
Ik voeg de uitkomst ook toe als hidden input.
Tijdens versturen wordt die uitkomst in database opgeslagen (dmv een WordPress "transient").
De invoer van invuller wordt vergeleken met uitkomst in database.
Daarna wordt de "transient" verwijderd uit database.
Doordat de "transient" niet meer bestaat, is de inzending niet bruikbaar voor een repeater bot die $_post hergebruikt.
(ik gebruik reeds de Post/Redirect/Get methode)
(transient is een tijdelijke entry in database, die ik dus gebruik om data op te slaan)
Echter ben ik er nu achter dat als je de uitkomst van je som meestuurt (gecodeerd/versleuteld of niet), dit altijd eenvoudig te manipuleren is. Kwam daar achter via de tool Burp Suite.
Los hiervan, ik loop tegen beperkingen aan van WordPress, omdat ik bv geen sessie mag gebruiken om data tijdelijk op te slaan.
Ik ga nu te ver off-topic, heeft niets meer te maken met mijn primaire vraag (over base64) ;-)
Guido
Guido - op 09/01/2024 10:19:36:
... omdat ik bv geen sessie mag gebruiken om data tijdelijk op te slaan.
Heb je dit ook daadwerkelijk geprobeerd via $_SESSION? En zo ja, wat werkt er dan niet? Krijg je een fotumelding?
Ik hoor wel dat er wordt geroepen dat bepaalde functies niet van Wordpress mogen? Maar draait dat niet om de specificaties voor publieke add-ons die je in hun download-store laat plaatsen? Bij een eigen besloten add-on mag je toch doen en laten wat je wilt, zolang je het uiteraard maar veilig houdt? ;-)
Ik kan een sessie gebruiken om data op te slaan en dat werkt prima. Alleen krijg ik binnen het dashboard een waarschuwing dat gebruik van sessies formeel niet toegestaan is. WordPress zelf gebruikt ook geen sessies, als ik me niet vergis is daarvoor gekozen omdat niet alle hosting providers het gebruik van sessies ondersteunen.
Guido
Guido - op 09/01/2024 23:49:56:
WordPress zelf gebruikt ook geen sessies, als ik me niet vergis is daarvoor gekozen omdat niet alle hosting providers het gebruik van sessies ondersteunen.
Waar las je dat? Elke hosting met PHP ondersteund wel sessies. Waarom zouden ze dat dan uitschakelen?