Help : Security issues
-
:wtf:hi guys , i m about to distribute a project to a client for the first time (the first ASP.NeT project, not the first time generally...:-)). anyway , i have a Q regarding the privacy of my code. the codebehind is compiled , but the ASPX pages aren't . (also my Javascripts are open wide , and although i remove the comments , i m still looking for a tool that will scramble it a bit...). the thing is , i don't want the client's SysAdmin to be able to see the ASPX pages (this way he can copy it to another network...). what i was thinking is to somehow store all of the ASPX files in one coded file , and Write an ISAPI extention that whenever a page from the project is requested , it will simply direct the ASP.NET parser to a portion of the file from the big packed file. can this be done? can a healthy extention can be placed before the ASP_NET parser and IIS , or will i have to do nasty hooking? any comment will be appriciated... david. :wtf:
-
:wtf:hi guys , i m about to distribute a project to a client for the first time (the first ASP.NeT project, not the first time generally...:-)). anyway , i have a Q regarding the privacy of my code. the codebehind is compiled , but the ASPX pages aren't . (also my Javascripts are open wide , and although i remove the comments , i m still looking for a tool that will scramble it a bit...). the thing is , i don't want the client's SysAdmin to be able to see the ASPX pages (this way he can copy it to another network...). what i was thinking is to somehow store all of the ASPX files in one coded file , and Write an ISAPI extention that whenever a page from the project is requested , it will simply direct the ASP.NET parser to a portion of the file from the big packed file. can this be done? can a healthy extention can be placed before the ASP_NET parser and IIS , or will i have to do nasty hooking? any comment will be appriciated... david. :wtf:
If you put your code in code-behind everything is compiled into a DLL. You must publish the aspx pages but there won't be anything on them when using code behind. The Javascript: I have a component to encrypt/decrypt javascript on the fly, not hack proof but a big deterent. He who laughs last thinks slowest.
-
If you put your code in code-behind everything is compiled into a DLL. You must publish the aspx pages but there won't be anything on them when using code behind. The Javascript: I have a component to encrypt/decrypt javascript on the fly, not hack proof but a big deterent. He who laughs last thinks slowest.
well, where / how should i insert it to the Codebehind? wont it make it much slower? there are many files , it will make the DLL much fatter, it will slow it down... about the JS encryption , these are 1500 lines of client code , won't it will make it much slower? (the interpreter has to decrypt it prior to running). DS.
-
well, where / how should i insert it to the Codebehind? wont it make it much slower? there are many files , it will make the DLL much fatter, it will slow it down... about the JS encryption , these are 1500 lines of client code , won't it will make it much slower? (the interpreter has to decrypt it prior to running). DS.
Select your aspx file. To insert code in code-behind goto the solution explorer and click the icon for code. Everything that is done on the page using <% etc. can be done here, (after all they are both server-side). You should be able to virtually copy and paste the code into the class and it will work the same. This is Microsoft's solution to separating code from content. As regards your question regarding speed. When an aspx file has code embedded on the page or in the code-behind class it is no different the first time the page is run it is compiled whichever method you choose. In other word there is not an iota of difference in speed, or performance. The major hit on performance with your application will come from 1500 lines of js whether it is code behind or on the page. About the js encryption, you are right it would affect the speed of operation as any ecryption would. I thought of another a solution to this, which would protect your js from the public but not from your ISP. It is to write an httpmodule which catches the request for a .js file. If the path is absolute reject the request. ie: If someone was to type in "http://xxx.com/xxx.js" to get your included library it would be rejected, your page request however would work just fine providing the call is not absolute. At the end of the day, they could still go in to the cache on their machine and copy the library after running your page. There is no secure way of protecting javascript. The question has to be posed is it in fact worth protecting, for the following reasons. If the person who wanted the script to put it in a commercial application, the chances are they are an accomplished programmer and would more than likely write it themselves anyway. If the person who wanted the script is a script-kiddie, what would he do with it anyway?. It is unlikely that it will be in a commercial product. If your ISP copied it you can see it and take lagal action. Lets face it Javascript is not difficult, and virtually anyone can write it. Hope this helps He who laughs last thinks slowest.