Chrome - Inspector element uitzetten via code (HTML)

[TheDiver]

Mede ontwikkelaars,

Ik heb flink gegoogled op mijn vraag maar geen duidelijke antwoorden kunnen vinden.

Het enige wat ik wil weten of het mogelijk is dat je via een code in je website het inspector elemant kan uitzetten in Chorme zodat andere bezoekers op je website geen info kunnen ophalen van je website?

Als iemand maar een ingang heeft ...ergens.. dan kom ik er wel uit.

THNX!

[RobIII]

Nee dat kan niet en daarbij hou je gewoon jezelf voor de gek. Bron weergeven kan altijd. Open voor de gein in notepad eens http://jesite.nl.

Je browser moet de HTML downloaden om de pagina weer te geven en dus kun je bij die HTML (en CSS en JS en whatnot). Een wget, telnet etc. zal exact diezelfde gegevens uitspugen als je er (op de juiste manier) om vraagt.

Geen mitsen en maren. Kan. Gewoon. Niet.
En totally useless.

Hoop dat dat wél een duidelijk antwoord is Maar uiteraard wel een dat je waarschijnlijk niet wou horen

[ Voor 61% gewijzigd door RobIII op 05-11-2014 11:26 ]

[TheDiver]

Thnx Roblll voor je snelle reply.

Eigenlijk is dit, security wise, een leuke uitdaging.

Groet!

[RobIII]

TheDiver schreef op woensdag 05 november 2014 @ 11:29:
Eigenlijk is dit, security wise, een leuke uitdaging.

Nee; dit heeft geen ene reet met security te maken. Als je niet wil dat mensen bij je HTML kunnen moet je je firewall dichtzetten of je webserver uitzetten. Als je wil dat mensen je site kunnen bezoeken moet je ze dus HTML serveren en die is dus per definitie te "zien".

Hier is werkelijk waar in de aller- allerverste verte "security wise" totaal géén "uitdaging" aan. Het illustreert alleen maar dat je niet helemaal goed begrijpt hoe het werkt

De vraag is: wat is je doel? Wat wil je precies bereiken hiermee? En waarom wil je dat bereiken?

[ Voor 39% gewijzigd door RobIII op 05-11-2014 11:36 ]

[sjoerddebruin]

Enige wat je zou kunnen doen is de rechtermuisknop uitschakelen, alleen is dat compleet funest voor de bruikbaarheid van je website. Met veiligheid heeft het niks te maken, wat wil je voorkomen?

[maarud]

RMB uitschakelen is wel het meest achterlijke wat er is. Op muizen waar de middelmuisknop afwezig is kan ik dus geen pagina's openen in een nieuw tabblad.

En bij de source kan je toch wel komen, waar je vervolgens alsnog de tekst en plaatjes kan kopiëren

[RobIII]

sjoerddebruin schreef op woensdag 05 november 2014 @ 12:05:
Enige wat je zou kunnen doen is de rechtermuisknop uitschakelen

Hij heeft 't specifiek over het "Inspector element" en niet het complete context-menu Los van 't feit dat dat ont-zet-tend 1996 is en irritant is, is 't ook nog eens gewoon not-done.

sjoerddebruin schreef op woensdag 05 november 2014 @ 12:05:
alleen is dat compleet funest voor de bruikbaarheid van je website

En daarbij totaal nutteloos. Het is in 0,3 seconden omzeild voor degenen die je HTML willen zien (CTRL+U om maar eens wat anders te noemen dan reeds eerder genoemde zaken).

Lang verhaal kort: forget it of haal je site offline. Pick one.

Zoals ik al eerder zei:

RobIII schreef op woensdag 05 november 2014 @ 11:31:
De vraag is: wat is je doel? Wat wil je precies bereiken hiermee? En waarom wil je dat bereiken?

TS zal dus duidelijker moeten zijn wat hij/zij bedoelt met:

TheDiver schreef op woensdag 05 november 2014 @ 11:23:
zodat andere bezoekers op je website geen info kunnen ophalen van je website?

[ Voor 38% gewijzigd door RobIII op 05-11-2014 12:14 ]

[Dido]

sjoerddebruin schreef op woensdag 05 november 2014 @ 12:05:
wat wil je voorkomen?

Dit lijkt me de essentiele vraag.

Zoals wel vaker is dit een vraag die eigenlijk een heel simpel antwoord heeft, maar die tegelijkertijd ook vertelt dat iemand een probleem probeert op te lossen met de verkeerde tool.

De TS heeft ons nu gevraagd of het mogelijk is om de kop van een hamer rond te laten draaien.

Zolang hij ons niet verteld dat hij een schroef in de muur wil krijgen kunnen wij hem niet vertellen dat er een schroevendraaier bestaat.

En met het antwoord "nee, dat kan niet met een hamer" schiet de TS ook weinig op, want de kans is groot dat hij door blijft zoeken naar een oplossing in dezelfde richting en uiteindelijk die schroef met een baksteen in de muur probeert te meppen. En dan 1) met stukken gebroken baksteen zit, 2) verwacht dat die schroef vastzit en 3) zich nog steeds afvraagt waarom zoiets nou zo moeilijk moet zijn.

[NMe]

TheDiver schreef op woensdag 05 november 2014 @ 11:29:
Eigenlijk is dit, security wise, een leuke uitdaging.

Als je dit soort niet-bestaande paardenmiddelen nodig hebt om iets te beveiligen, dan doe je iets niet goed. Beveiliging hoort in je serverside-code, niet in de HTML die uiteindelijk naar je gebruiker gaat.

[TheDiver]

Simpel: ik wil niet dat gegevens van mijn DB (of naam van de DB) of re-direct IP zichtbaar zijn. Die zijn of kunnen door deze tool wel openbaar worden gemaakt.

Dit vraag ik omdat ik recentelijk een audit heb gedaan voor een grote webontwikkelaar (die hier het antwoord niet op wist). Ik ben dus bij klanten van hen zaken tegen gekomen die openheid van zaken lieten zien middels deze tool.

Nu met het SSL3 gebeuren kan een MitM makkelijk plaats vinden als bijv het IP adres al zichtbaar is in deze tool .... erachter komen op welke cipher het draait maakt dan niet uit en is kinderspel om het te achterhalen.

Mijn toegangsdeur is de website ....naar de server toe. Iets wat ontwikkelaars btw veel vergeten

[ Voor 3% gewijzigd door TheDiver op 05-11-2014 13:10 ]

[Stoffel]

Ik mag hopen dat je geen security audit bedoelt, want het enige dat ik uit het verhaal hierboven haal is dat je werkelijk waar helemaal niets begrijpt van hoe een webapplicatie in elkaar zit en werkt. Connection strings in de HTML

[maarud]

Als je de connection gegevens in PHP zet en correct verwerkt, dan ziet de eindgebruiker die niet eens. Dus als dat wel zo is, is dat niet goed gemaakt

[JJerome]

Je probeert een "probleem" op te lossen dat niet bestaat. En ik heb eigenlijk het vermoeden dat je geen idee hebt hoe websites werken. Je probeert de broncode te verbergen die een browser nodig heeft om de website te renderen, wat sowieso niet kan en ook nog eens helemaal niets oplost. Daarnaast heb je het over het verbergen van een IP-adres omdat daarmee een MitM zogenaamd kinderspel is. Wat ook een volledig verkeerde redenatie is, en wederom onmogelijk.

Als je uitlegt welk probleem je daadwerkelijk hebt dan kunnen we je misschien wat advies geven.

[Dido]

TheDiver schreef op woensdag 05 november 2014 @ 13:09:
Simpel: ik wil niet dat gegevens van mijn DB (of naam van de DB) of re-direct IP zichtbaar zijn. Die zijn of kunnen door deze tool wel openbaar worden gemaakt.

Wat doet de naam van jouw database in je HTML?

In feite vertel je nu dat jij jouw creditkaart aan een touwtje op je rug hebt hangen, en je zoekt nu een tool om te voorkomen dat iemand aan je creditkaart zit.

De daadwerkelijke oplossing is gewoon je creditcard opbergen, natuurlijk. En als je die in je kontzak stopt, ben je ook wat dichter bij het antwoord waar je database(naam) hoort: je back-end.

[NMe]

TheDiver schreef op woensdag 05 november 2014 @ 13:09:
Simpel: ik wil niet dat gegevens van mijn DB (of naam van de DB) of re-direct IP zichtbaar zijn. Die zijn of kunnen door deze tool wel openbaar worden gemaakt.

Je weet blijkbaar het verschil tussen clientside en serverside niet. Als je je daar eens op gaat focussen dan hoef je je tijd niet te verspillen aan het oplossen van een XY-probleem van epische proporties.

Mijn toegangsdeur is de website ....naar de server toe. Iets wat ontwikkelaars btw veel vergeten

Klopt, maar dat heeft niks te maken met de tekst en opmaak die je toont. Als jij inderdaad DB-gegevens in je HTML, CSS of Javascript parkeert dan ben je nogal kwetsbaar, maar tegelijkertijd ben je dan, no offense als je dit echt doet, een beroerde programmeur.

[ Voor 26% gewijzigd door NMe op 05-11-2014 14:23 ]

[Barryvdh]

TheDiver schreef op woensdag 05 november 2014 @ 13:09:
Nu met het SSL3 gebeuren kan een MitM makkelijk plaats vinden als bijv het IP adres al zichtbaar is in deze tool .... erachter komen op welke cipher het draait maakt dan niet uit en is kinderspel om het te achterhalen.

Je kan je server wel instellen dat SSLv3 niet meer geaccepteerd wordt. http://askubuntu.com/ques...lnerability-cve-2014-3566

[NMe]

Barryvdh schreef op woensdag 05 november 2014 @ 14:26:
[...]

Je kan je server wel instellen dat SSLv3 niet meer geaccepteerd wordt. http://askubuntu.com/ques...lnerability-cve-2014-3566

Bovendien los je die SSL-problematiek in zijn geheel niet op door domweg de HTML af te schermen, zelfs als het kon.

[everlaat]

Blijf ontopic of reageer niet

[ Voor 75% gewijzigd door BtM909 op 05-11-2014 16:54 ]

[André]

Ik denk dat hij tools op een website loslaat die met suggesties komen, alleen is de interpretatie daarvan zwaar gebrekkig? Ik geloof er niets van dat als je het verschil tussen client of serverside niet eens weet je wel de beveiliging van een website kunt beoordelen.

[Mavamaarten]

Als er connectiestrings voor je SQL server in de HTML staan die je clients te zien krijgen, dan is er inderdaad een serieus beveiligingsprobleem aanwezig. Maar dat ga je niet kunnen oplossen door een contextmenu-item te verbergen op je site

[BtM909]

TheDiver schreef op woensdag 05 november 2014 @ 11:23:

Het enige wat ik wil weten of het mogelijk is dat je via een code in je website het inspector elemant kan uitzetten in Chorme zodat andere bezoekers op je website geen info kunnen ophalen van je website?

Doel je niet stiekem op de console uitschakelen (zoals Facebook)