Variabel in andere file linken naar html

[Kra5313]

ik heb een script gemaakt dat eigenlijk gewoon een formulier is waar je een wachtwoord moet invoeren om naar de beheerderspagina te gaan. toen ik alles dubbelcheckte, merkte ik dat het script inclusief het wachtwoord met inspect-element kan worden gezien. Ik ben nog steeds bezig met het leren van php, javascript, html en css en ik kan er niet achter komen hoe ik dat wachtwoord in een apart .js-bestand kan plaatsen en het terug kan koppelen aan mijn wachtwoordcode.

Dit is de code die ik heb geschreven. ik hoopte dat iemand me zou kunnen vertellen hoe ik het wachtwoord in een apart bestand kan opslaan en het terug kan koppelen


<h3>admin<h3>
<form>
<label for="pswd">Enter your password: </label>
<input type="password" id="pswd">
<input type="button" value="Submit" onclick="checkPswd();" />
</form>
<!--Function to check password the already set password is Kra5313-->
<script type="text/javascript">
function checkPswd() {
var confirmPassword = "kra5313";
var password = document.getElementById("pswd").value;
if (password == confirmPassword) {
window.location="/admin/Stored Ips.php";
}
else{
window.location="/sub pages/you_tried.php";
}
}
</script>

[Vloris]

Ik denk dat je vooral even moet verdiepen in cliënt-side uitgevoerde code (in de webbrowser, JavaScript dus) en server-side (op de webserver, voor-verwerking van de html en evt. css en JavaScript die überhaupt naar de browser gaat, php dus).

Als je password checks in JavaScript gaat doen is dat sowieso leesbaar voor iedereen die je website bezoekt en snapt hoe inspect werkt.

[n9iels]

Alles wat in de browser draait, dus je HTML en Javascript code, zijn openbaar. Wachtwoorden en andere geheime informatie plaats je dus nooit in code die in een browser zal worden uitgevoerd. Wat je wilt doen is het ingevulde wachtwoord opsturen naar jou server en met PHP het verder afhandelen. Een linkje om je op weg te helpen: https://www.w3schools.com/php/php_superglobals_post.asp

Als je dit concept door hebt is het ook goed om eens wat verder te kijken hoe je een wachtwoord nou eigenlijk opslaat. Dit doe je namelijk nooit als platte tekst, een wachtwoord wil je altijd als een hash opslaan. Neem daarvoor eens een kijkje in de documentatie van PHP zelf: https://www.php.net/manual/en/function.password-hash.php. Maar begin eerst met de basis van het opsturen van formulier data Als je dat onder de knie hebt kun je verder bouwen.

Edit. Nog een tipje voor de volgende keer, als je een topic start met wat code, plaats deze even tussen de

code:

[code][/code]

tags. Maakt het wat overzichtelijker

[ Voor 12% gewijzigd door n9iels op 03-10-2022 19:44 ]

[Haan]

Een wachtwoord zet je never nooit niet client-side (in javascript).

Als je het zo basic wilt houden als je nu hebt, controleer je het wachtwoord server-side in je php script, maar gebruikelijker is natuurlijk om gewoon een nette inlog te maken met een database waarin je users en rollen hebt staan.

[RGAT]

Dat doe je door het niet in Javascript te doen, dat wordt namelijk op de computer van je gebruiker uitgevoerd dus apart bestand of niet, diegene zou gewoon het wachtwoord kunnen lezen

Wat je 'hoort' te doen met wachtwoorden is het hashen (niet met SHA1 of MD5 maar SHA256 bijvoorbeeld) en het vergelijken met wat in de MySQL (of andere software) database staat middels PHP op de server.

Wat je hier doet is het wachtwoord checken in Javascript bij de client uitvoeren, die client kan het wachtwoord dus lezen of gewoon de hele check weghalen. Als de code in PHP op de server wordt uitgevoerd kan de client die niet zien/aanpassen.

Oftewel flink wat meer inlezen in o.a. :
Hash/hashing/PHP's ingebouwde functies hiervoor
Salt (voor bij hashing)
SQL/database
PHP database connecties

Zeker niet in Javascript je login code schrijven, tenzij je gehackt wilt worden

[luukvr]

RGAT schreef op maandag 3 oktober 2022 @ 19:42:
SQL/database
PHP database connecties

Beetje overkill als je maar 1 gebruiker hebt en lerende bent, kan ook gewoon hardcoded. Verder valide punten als je een gebruikersdatabase met andermans gegevens gaat aanleggen.

[RGAT]

luukvr schreef op dinsdag 4 oktober 2022 @ 10:35:
[...]


Beetje overkill als je maar 1 gebruiker hebt en lerende bent, kan ook gewoon hardcoded. Verder valide punten als je een gebruikersdatabase met andermans gegevens gaat aanleggen.

Maar wat ben je dan lerende behalve hoe je dit (goed) doet?
Hardcoded heeft er verder niets mee te maken, of je het nou hardcoded in PHP of de database zet maakt kwa veiligheid 'weinig' uit als test om het te leren, het gaat erom dat je beveiliging niet aan de bezoeker over laat.

Wat je nu doet is de bezoeker een script meegeven waarin het wachtwoord staat maar ook wat er gebeurt als je het juiste wachtwoord invoert. De gebruiker kan het wachtwoord dus gewoon lezen of het script volgen en zonder in te loggen alsnog 'ingelogd' zijn.

Code om in PHP uit een database te laden is ongeveer 3 regels aan code, niet bepaald overkill zeker als je dat soort zaken juist aan het leren bent

[CodeCaster]

Om sec je vraag te beantwoorden:

HTML:

<script src="password.js"></script>

Dan wordt de inhoud van dat script geïncludeerd in de globale scope, oftewel alle scriptbestanden kunnen bij elkaars variabelen.

(Idealiter gebruik je daar import/export voor, modules: https://stackoverflow.com...nother-file-in-javascript)

Dus als er in die password.js-file dan staat:

JavaScript:

var confirmPassword = "kra5313";

Dan kun je jouw code aanpassen:

JavaScript:

if (password === window.confirmPassword) ...

En dan vraag je deze pagina op, druk je op F12, tik window.confirmPassword, en dan zie je dat het "verstoppen" van de variabele in een ander bestand geen enkel nut heeft, de gebruiker kan er nog steeds bij. Zie de overige antwoorden voor oplossingen.

Sowieso kan iedereen navigeren naar /admin/Stored Ips.php; als je daar niet ook een authenticatie- en authorisatiecheck op hebt, is deze check alleen voor de bühne.

[ Voor 9% gewijzigd door CodeCaster op 04-10-2022 10:49 ]

[LordSinclair]

RGAT schreef op dinsdag 4 oktober 2022 @ 10:39:
[...]


Maar wat ben je dan lerende behalve hoe je dit (goed) doet?

Lerende doe je in stapjes en niet alles tegelijk. Dus eerst kan je het gewoon hardcoded serverside controleren. Daarna kan je het uitbouwen met een database en alles erbij.

[luukvr]

RGAT schreef op dinsdag 4 oktober 2022 @ 10:39:
[...]


Maar wat ben je dan lerende behalve hoe je dit (goed) doet?
Hardcoded heeft er verder niets mee te maken, of je het nou hardcoded in PHP of de database zet maakt kwa veiligheid 'weinig' uit als test om het te leren, het gaat erom dat je beveiliging niet aan de bezoeker over laat.

Het probleem gaat hier inderdaad over server vs client sided code.

Een database gebruiken maakt het niet perse beter, is een schaling-oplossing wat uit de code blijkt niet nodig te zijn.

Hashing en salts lossen andere problemen op en is pas een verplichting als je andermans wachtwoorden gaat opslaan. Grootste gevaar is dat je dat ene 'wachtwoord' niet meer kan gebruiken.

TS is duidelijk een beginner, niet nodig om hem/haar te overspoelen met technieken.

[AW_Bos]

Iedereen is een beginner. Het voorbeeld van de TS is leuk om mee te oefenen, maar in de praktijk onbruikbaar omdat je de sleutel meteen weggeeft aan de bezoeker, die even goed moet zoeken. Hoogstens is het leuk voor een online escape-room .

Het voordeel van serverside opslaan, en het gebruik van een database is, is dat je de eigenaar van het wachtwoord ook de mogelijkheid geeft om deze aan te kunnen passen. Niet is zo vervelend als een vast wachtwoord in de broncode, waarbij iemand die het heeft laten lekken afhankelijk moet zijn van een programmeur (die misschien wel aan het genieten is van een welverdiende vakantie). En laat de gebruiker dus de mogelijkheid hebben om deze te kunnen resetten.

Mocht je een paar tips willen voor een serverside loginsysteem:
- Sla het wachtwoord op met een goed algoritme, zoals bcrypt, en in PHP met password_hash() en controleer met met password_verify()
- Bij het volgen van de procedure van iemand om een wachtwoord op te halen, zorg dat je deze nooit in een mail laat zien. Geef de gebruiker de keuze om een wachtwoord te bedenken via een tijdelijke eenmalig te gebruiken activatie-link in een mail
- Accepteer alleen sterke wachtwoorden. Minimaal 8 tekens en afhankelijk van je site kan dit nog aanscherpen met wat extra vereisten, zoals cijfers en speciale tekens.
- Bij een poging om het wachtwoord te raden geef je enkel aan dat 'gebruikersnaam en/of wachtwoord niet correct zijn'. Je wilt nooit prijsgeven of een gebruikersnaam al goed is of het wachtwoord. Het is immers geen Mastermind-game.
- Sla nooit wachtwoorden op in cookies of in sessies. Je bent immers al geauthenticeerd, dus daarom zou je dat gegeven nog nodig hebben?
- Bouw in systeem in om een account te bannen/deactiveren.

Pro-tips:
- Zorg voor brute-force detectie, en gooi IP's op de blocklist die in korte tijd blijven proberen.
- Gebruik twee-staps verificatie (MFA/2FA). Bij voorkeur met dit pakket:
https://github.com/PHPGangsta/GoogleAuthenticator
- Controle op spammers door te kijken met geo2location op afkomst, en dan eventuele drempels tonen met captcha's of complete weigeringen van toegang.

[ Voor 9% gewijzigd door AW_Bos op 04-10-2022 12:53 ]

[RGAT]

luukvr schreef op dinsdag 4 oktober 2022 @ 10:57:
[...]


Het probleem gaat hier inderdaad over server vs client sided code.

Een database gebruiken maakt het niet perse beter, is een schaling-oplossing wat uit de code blijkt niet nodig te zijn.

Hashing en salts lossen andere problemen op en is pas een verplichting als je andermans wachtwoorden gaat opslaan. Grootste gevaar is dat je dat ene 'wachtwoord' niet meer kan gebruiken.

TS is duidelijk een beginner, niet nodig om hem/haar te overspoelen met technieken.

Ik zeg dan ook niet dat TS nu vijf minuten heeft om een perfecte, onhackbare oplossing neer te zetten welke de wereldwijde standaard wordt
Het is puur een (incompleet) lijstje met steekwoorden/onderwerpen waar TS mee aan de slag kan om te leren, TS kan dan zelf het eigen tempo en diepgang bepalen maar weet iig in welke hoeken die kan gaan doorleren, iig zo ver weg mogelijk van Javascript 'authenticatie'

[BernardV]

Doet me denken aan deze: https://net-force.nl/challenge/level101/