Tag Info

Hot answers tagged

77

A malicious hosting provider can do a lot more than simply steal your code. They can modify it to introduce backdoors, they can steal your clients' data, and ruin your whole business. Trust must exist between you and the host. About the source code. If the attacker is trying to gain access to your source code, they will gain access to your source code, ...


77

First of all, your security guy is likely right. It doesn't look like you have anything to worry about because from your description of the issue and the guy's response I think that the script tags were properly encoded. Think of it as a neutralized weapon. It's there, yes, but it cannot do any damage. Running that code through a deobfuscator gives us ...


52

To understand this, we must understand how crawlers find the email. While steering away from the technicals, the basic idea is this (today's algorithms are, of course, smarter than that): Find @ in the page. Is there a dot within 255 characters after the @? Grab what's behind the @ until you reach a space or the beginning of the line. Grab the . and what's ...


32

Well, this calls for three comments: You cannot protect secrets with code obfuscation. Not really. Code obfuscation somehow works against unmotivated attackers, but it is not strong. If there is commercial value in breaking through it, then it will happen. If you don't trust your hosting service then look for another hosting service. If the secrecy of your ...


27

No, it isn’t worth it. Nobody wants to steal your code. A thousand million SaaS products have been launched by individuals and companies using third-party hosting of some description or another, and roughly none of them have found themselves to be competing against themselves after having the code for their products stolen by their hosts. So, should you ...


18

In addition to Adnan's answer: This is a by-product of when an attacker fuzzes your application (he just sends tons of payloads to see if one works). If your application handles encoding and escaping of user input correctly, you should not need to worry about being vulnerable. There are some countermeasures you can take to reduce these attacks such as ...


13

Obfuscation might look as the first obvious step, but obfuscation has to protect something in the code and that something cannot be webservice functionality because that is reverse engineered by intercepting the traffic even if it is SSL encrypted. Certificate pinning can prevent simple SSL interception by trusting a predefined certificate. You can ...


12

Obfuscation is ineffective against a determined attacker, it only makes it slightly more difficult. If you have a particular reason to distrust your hosting provider, get another. If you just want to be safe, get a non-disclosure agreement and other legal assurances that allow you to go after your host if they abuse things. If you still don't trust ...


10

I think the operative word in the question is "afraid." The aversion is based on fear, not fact. The reality is, the threat model isn't particularly realistic. Commercial web software development companies nearly universally use JavaScript these days, obfuscated or otherwise, and I challenge you to find me even a single example of one that's had it's JS ...


9

Nasty little bit of code It's likely a botnet setup or a backdoor for script kiddies. Would need to see what they're passing as vars and URLs to tell you what they're hitting you with, but this is a backdoor test script that tries several known exploits to pass information to your server. They're usually injected either via MySQL Injection Attack and ...


9

I wouldn't bother. Two reasons: Runtime interpreted languages really cannot be fully protected that way. To completely obfuscate it you would have to obfuscate it from the runtime as well, then there would be no way to execute it. Obfuscation just makes the task slightly more annoying. It can also make debugging and deployment more time consuming for ...


9

Fundamentally you cannot secure your client. At best you can obscure and obfuscate in order to make it more difficult for an attacker to modify the client. You mention that it is not a security issue because the server is properly secured, but merely an annoyance. It may be more annoying to try to obscure your client than to let a few modified clients make ...


8

To my humble opinion, email obfuscation (of any sort) is one of the worse ideas ever invented. The foremost concern for any user interface, web based or any other, is convenience and safety of its users. Spam bots are not users, thus they are not worth any consideration or effort. The logic goes as following: E-mail obfuscation is a nuisance for ...


7

I have never understood the paradigm since its conception. We are simply depriving spam battling software the necessary data. As mentioned before, adding "at" "dot" to the parser is trivial too. I would actually urge otherwise. Let the hell loose. Use your email and use any email for that matter. I even wrote a bot 10 years ago or so, where it produced ...


6

You should take precautions to protect yourself, but not for the reasons or from the threat that you're imagining. First of all, if you can't trust your hosting provider, get a new hosting provider. No more needs to be said about that. Second, even though you think that the intellectual property in the web application you've built is valuable, chances are ...


5

I have many web applications hosted online. Some code is valuable yes. However, I did not obfuscate any of it since even if it gets stolen, no one else can maintain it. They will eventually pull their hair out. I tried it with someone who wanted my software badly. He could not install it, understand it nor get anything out of it so how would he be able to ...


5

The world is upside down, the real value is usually not in the application code. It's in the customer data that the code is used to gather/modify. In many web applications the code is secured and the data sits in plaintext often without any simple protection. This is one of the issues that PCI DSS, HIPAA, and other data security standard are meant to ...


5

When you don't trust your hoster to not steal your data, you should look for a more trustworthy hoster or host yourself. You are not just entrusting your program code to them, you also entrust all your data and the data of all of your users. When you assume that your hoster is malicious enough to steal your programming, they are also malicious enough to ...


5

There is no security merit in attempting to obfuscate any client-side code. A determined enough attacker will bypass any obfuscation methods you throw at them. If the code is really important, keep it on the business side. Consider any client-side code public and available to anyone and everyone.


5

The article actually describes two constructions, the second one using the first one as a building tool. The first construction provides indistinguishability obfuscation while the second one is functional encryption. Indistinguishability obfuscation is a rather esoteric property, which is not what non-academic think about when they hear "obfuscation"; the ...


4

DotFuscator will "encrypt" string literals, although I cringe at the use of the word "encryption" in that context. Your string values "AppInformation7653" and "GG3MDhlxnZDdDx7" won't appear "as is" in the resulting assembly, but the code necessarily contains everything that is needed to rebuild their respective values at runtime. So don't believe that such ...


4

Well there are more complex obfuscation techniques. For instance metamorphic and polymorphic malware. There is an article on searchsecurity by Margareth Rose detailing how this works: Metamorphic and polymorphic malware are two categories of malicious software programs (malware) that have the ability to change their code as they propagate. ...


4

You seem to already know that obfuscation isn't actual protection, so I'm not gonna lecture you on security by obscurity. What makes sense is this: Put your competitive code on the server to protect it, then obfuscate client-side code as much as you want. Granted, it won't give you much security but it'll definitely deter kiddies snooping around, and it'll ...


4

Obfuscation never hide or change your Code, it just modifies it into some other format in which it can process it, Ex: if you want to obfuscate your class name MyHomePage my be changed into M4Page Similarly a method of addWidgets() will be named in some other, and the function name might also be changed, not the Functionality So if i wish to call the ...


3

You can't obfuscate your code or data enough to make them secure. If you were able to, your code and data would be unusable to even you. Security via obscurity only works so long as the secret of your obfuscation remains intact. Secrets never stay secret. This is the basis for most digital rights systems, and to date all of them have been cracked. On a ...


3

No. Clearly: You're planning to invest time in a so called security through obscurity technology. I'ts not a good idea! To protect your idea against third part licensing, you could publish them under such a public license like GNU GPL, creative commons or others.


3

Of course this is a baseless fear. Javascript is only one part of a larger ecosystem, much more important is brand, site usability, site integrity, responsiveness and network effects. Yeah, javascript minimisation, optimisation is good to do, but not because of these purposes. If a competitor steals you code, you can go legal on their tails, and kill ...


3

There have been a few implementations of fully homomorphic encryption (2010). Fully homomorphic means it can perform addition AND multiplication (as opposed to partially homomorphic). The answer to your question though relies on what you consider "weak" and sufficient for security. Does the encryption have to stand up for 100 years, or is it OK if it's ...


2

Your public class and method names won't change, because they're externally referenceable, they can't. Since public types may be used by other libraries and applications that the obfuscator has no knowledge off, they must be preserved. As to the string values, they may or may not be obfuscated. They usually are, but I haven't used DotFuscator, so I ...



Only top voted, non community-wiki answers of a minimum length are eligible