Website Source Code Thought
-
We're able to view any website's HTML and in (almost) all cases, the javascript code as well. Might sound a bit silly but any website out there which actually tries to protect it's code from the viewer? Javascript and probably CSS can go in protected mode by including the files in the html or aspx pages than including them in the main page itself. Can this improve a website's security by any way?
My Blog My Achievements: * Posted 25,000th message in GIT O_O * Official supporter of the "thatraja's GIT Meet Sponsor Foundation" :D What you do, when you don't know what to do is what you do when you don't want to do what you do.
In all my years of web-surfing, I have successfully come across a single site that successfully protects its information (More than its code really) The server reads the information from a database, horrifically muddles the order of the words, splatters them in the code, then uses some rather funky CSS to make the text perfectly readable to the viewer. This makes it impossibly to simply copy-paste information from the site. I can't remember which site specifically, but it was awesome :laugh:
-= Reelix =-
-
In all my years of web-surfing, I have successfully come across a single site that successfully protects its information (More than its code really) The server reads the information from a database, horrifically muddles the order of the words, splatters them in the code, then uses some rather funky CSS to make the text perfectly readable to the viewer. This makes it impossibly to simply copy-paste information from the site. I can't remember which site specifically, but it was awesome :laugh:
-= Reelix =-
yeah, it was, i hope you remember
-
Ultimately, you can't hide the JavaScript. The browser has to be able to get to it to run it, which means that a copy has to "come to" your machine.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Perhaps someday we will have "compiled Javascript" where instead of the browser downloading the Javascript source, it downloads a compiled binary of the Javascript to run in some sort of VM (a la Java or .NET)... then again, that's essentially how Java applets and Silverlight work, apart from the source being Javascript! But perhaps someone has written a compiler that turns Javascript into JVM or CLR bytecode already?
-
Well you could use serverside javascript or indeed any other language for any functionality you don't want publicly visible
You can do that. Or you could use your server side language.... The problem comes in when the JS or client side code must run on the client. In those cases... it must run on the client. If the client can run it, the client can see it.
-
I thought that Silverdark was obfuscated. :-D
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
In all my years of web-surfing, I have successfully come across a single site that successfully protects its information (More than its code really) The server reads the information from a database, horrifically muddles the order of the words, splatters them in the code, then uses some rather funky CSS to make the text perfectly readable to the viewer. This makes it impossibly to simply copy-paste information from the site. I can't remember which site specifically, but it was awesome :laugh:
-= Reelix =-
The "funky CSS" won't help those who use a screenreader or other accessibility device, and it is horribly prone to breaking. In addition, this causes problems in case you ever want to access that information easily (viz. without firing up your SQL program and manually finding the information, in this case). Also, you're not preventing people copying it, you're just slowing them down. Ultimately, this whole practice of obfuscating HTML (CSS and JS not quite as much, but it's still silly) is antithetical to the entire framework of the web - it's like trying to keep people from taking pictures of billboards. The entire point of the public web is to disseminate information - making it harder to do so helps no one. If you can't trust the public with your information, don't give it to them - use a user system. Don't waste an enormous amount of time defeating the whole point of your site in the first place.
-
We're able to view any website's HTML and in (almost) all cases, the javascript code as well. Might sound a bit silly but any website out there which actually tries to protect it's code from the viewer? Javascript and probably CSS can go in protected mode by including the files in the html or aspx pages than including them in the main page itself. Can this improve a website's security by any way?
My Blog My Achievements: * Posted 25,000th message in GIT O_O * Official supporter of the "thatraja's GIT Meet Sponsor Foundation" :D What you do, when you don't know what to do is what you do when you don't want to do what you do.
As stated elsewhere, HTML is intended to be read, not hidden. The original intent of JavaScript was open source because the code is supposed to be passed to the client and the client is responsible. I don't know how JavaScript can be protected by putting it in a file, the file is still linked in order to access it and it has to have read access for the client to read it. There are methods that remove access to some code access. Calling a web service has a public method of accessing it, but in a proper setup all the code of the service should be hidden. In ASP, you can run JavaScript on the server side so that source is protected. Of course you won't even see they are running JavaScript. There are various ways that code can be protected. One of them blew me away. I had this task to provide client specific information. We had a client authorization environment built in but several clients needed access to ONLY their information and I was trying to pick and choose what information each client could see. I set it up so each client would access a different file and obsfucated the file name so the client couldn't guess another name. Imagine my surprise, my cgi sent XML and the source I got was HTML. The file name was irrelevant.
-
The "funky CSS" won't help those who use a screenreader or other accessibility device, and it is horribly prone to breaking. In addition, this causes problems in case you ever want to access that information easily (viz. without firing up your SQL program and manually finding the information, in this case). Also, you're not preventing people copying it, you're just slowing them down. Ultimately, this whole practice of obfuscating HTML (CSS and JS not quite as much, but it's still silly) is antithetical to the entire framework of the web - it's like trying to keep people from taking pictures of billboards. The entire point of the public web is to disseminate information - making it harder to do so helps no one. If you can't trust the public with your information, don't give it to them - use a user system. Don't waste an enormous amount of time defeating the whole point of your site in the first place.
-
You can do that. Or you could use your server side language.... The problem comes in when the JS or client side code must run on the client. In those cases... it must run on the client. If the client can run it, the client can see it.
-
HTML is just markup - fancy formatting for text - so "protecting" it is like protecting the text you're displaying to the user. ie kinda pointless. CSS is just styling and layout, so the same deal. However, one minor niggle here is that maybe you have content on your site you don't want some people to see (hidden link, hidden that only spiders and bots will see). In this case the HTML and CSS could be used to hide stuff, and so obfuscating this may be useful. That is, if hiding ocntent on a webpage is useful. Javscript obfuscation is well known and falls into the same bucket as any other obfuscation such as .NET binaries.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Javascript obfuscation is at times just a side effect of compression. By reducing identifier lengths to just 1-2 characters, removing whitespace and newlines, inlining method definitions and the like, you can decrease your Javascript's size to half. Only, this completely eliminates any trace of readability.
-
Javascript obfuscation is at times just a side effect of compression. By reducing identifier lengths to just 1-2 characters, removing whitespace and newlines, inlining method definitions and the like, you can decrease your Javascript's size to half. Only, this completely eliminates any trace of readability.
Real Web Developers read and write minified Javascript faster than unminified. It's shorter, after all.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
We're able to view any website's HTML and in (almost) all cases, the javascript code as well. Might sound a bit silly but any website out there which actually tries to protect it's code from the viewer? Javascript and probably CSS can go in protected mode by including the files in the html or aspx pages than including them in the main page itself. Can this improve a website's security by any way?
My Blog My Achievements: * Posted 25,000th message in GIT O_O * Official supporter of the "thatraja's GIT Meet Sponsor Foundation" :D What you do, when you don't know what to do is what you do when you don't want to do what you do.
As others have pointed out, any file used on the client side, whether HTML, JavaScript, CSS, or anything else, has to be sent to the browser for the page to work, and therefore can't be locked away. If a browser can't read it, the page won't work; if a browser can read it, a person can read it. However, it is worth mentioning that there is, indeed, a security implication to this: the user can do anything he or she wants on the client side: run a custom browser, modify the HTML or JavaScript you sent out, and so on. There are lots of tools for doing this, some of them for developers and others for people who like to modify CSS so they can look at pages the way they want to see them. In any case, what this means is that client-side code is never secure. You can't ever be sure that the code you sent is the code running on the user's computer, which means that you cannot automatically trust input coming back to the server from it (nor can you really send data that you want the client-side code to process but that you don't want the user to have access to). Most people know that you have to treat user input carefully to avoid things like SQL injection attacks, but really you need to realize that "user input" doesn't just mean form field values, it means anything coming from the user side, even values generated completely by your script...because it may or may not be your script that your server is actually talking to.