Related
I don't mean to be vague, but I'm skeptical of the idea of releasing code that is intentionally turned off, and I've not been able to find any good sources relating to the subject. This may truly be a "it depends" question, in which case please feel free to down vote and remove.
My specific context is a web app that we host ourselves, with bi-weekly "releases" (push to production). Also, we currently use Subversion, though there's a push to move to Git in the near future.
One scenario I've heard is deploying a feature that is dependent upon a library with a known feature that hasn't been released yet, whether your own library, or a 3rd party's.
Another is releasing portions of a feature as they are finished, but disabled until all the pieces are together in production.
While both of these at first sounded good, I'm questioning the value of code living in production that is disabled, especially as a general practice. It seems like this could lead to unfinished features cluttering the code base, as well as leading to larger configuration files than are needed, just to provide means for disabling/enabling features.
What, if any, are the benefits of deploying intentionally disabled code, and what concerns need to be addressed before we do this with any sort of frequency?
Also, please share any links, and tell me if this practice has a name.
It is called feature toggles
I'd argue that it is no more risky that enabling/disabling features using role-based-authorizations. Your concerns regarding code clutter and increased configurations are valid but advocates of continuous delivery would argue that the alternatives (feature branches) are worse.
The primary basis for doing this I've seen is to separate code pushes from configuration pushes. It's easier to determine whether you have a bad release or bad configuration if you can separate them. You can push a release with incomplete feature X off by default, continue to push releases that can be rolled back without enabling it, then when you decide to turn it on, you can update your config which can also be rolled back if needed.
Recently we developed and published a mobile banking app on the app store, for a big banking organization. The bank hired a security firm to perform ethical hacking over the app to see if it, in anyways compromises confidential data.
We recently received the hacking report from the firm, which in-spite of saying that no serious security issues are present, contains a list of all the class files, method names and the assembly code of the project.
Now the client insists that we fix these security loop holes and republish the app. However we don't have any idea how did they manage to get all these details from the application's IPA. I searched this over SO and found a particular post mentioning this link, which states that you can't save your app from being hacked.
Please help me how to fix these security vulnerabilities , or if not possible, how to convince the client.
Edit:
Recently came across this page. Seems like EnsureIT from Arxan can prevent app IPAs from reverse engineering. Anyone experienced with this?
There's always a risk involved. Even if you don't introduce vulnerabilities yourself, the platform may allow for exploits which in the end may offer an entry point for a malicious attacker.
As to your question: It is not safe to assume that a hardcoded URL, even if obfuscated beyond belief, can't be peeled out of your product. Always design your apps such that safety of user data is guaranteed (as far as possible) even if built in ressources get compromised. If the knowledge of that URL alone poses a security threat, then your whole approach and your clients API is inherently insecure. Remember that such information could possibly be captured by a man-in-the-middle attack (and other modes of attack) as well.
Avoid security by obscurity. Store sensitive data only on disk if it is necessary. As a rule don't allow PIN / TAN storage.
Some thoughts which may (or may not) convince your client that your app is as safe as it can be:
As long as the app runs on a non-jailbroken device, it is unlikely that an attacker, even with knowledge of your apps internals is able to get to any user data, because the iPhone normally doesn't offer opportunities to interfer with your app
If the attacker is able to get to your users data, and provided you have been protecting that data with all means available under iOS (-> keychain -> crypto chip ->...), then it's not your fault. It means the device is either jailbroken or there are vulnerabilities to the system itself which have been exploited, you just can't do anything about either possibility.
It is impossible to prevent reverse engineering of your app. Even if you had put more effort into obfuscation, an attacker with strong motivation would still be able to get what he wants. Your client needs to get used to this as it's a fact.
Other platforms suffer from similar vulnerabilities, yet on the iPhone at least you have a somewhat closed environment and a reduced risk of being attacked with trojans and the like.
The governments and security firms get hacked on a regular basis, although they should now how to protect themselves. This means life is inherently insecure, cope with it.
I was recently researching over this and I found this article helpful, especially the part quoted:
The code for a native app is stored in the form of a binary executable file, which is further encrypted; its decryption is performed only when the executable file is loaded by the processor into the random access memory and the whole decryption process happens at the hardware level. That is why it is very hard to create offline decryption tools. The only way to decrypt encrypted binary data is on a jailbroken device with a few special tools installed.
Security in iOS: Protecting .ipa File Content by Stoyan Stoyanov
This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
IE6: To support or not to support.
Should we support IE6 anymore?
I'd hate to (HATE TO) admit it, but there are some people still using this browser. A client of mine is facing an issue where the "transparency" area of a png comes out a light grey - ONLY on IE6.
I know it's an unsupported browser, but some people STILL use it. I'd love to have a little discussion about whether or not I should choose to support it.
One point pro-support of IE6 is that often in large organisations, the update of systems is often unimportant to their IT department, so theres a large proportion of people working in these organisations that still use IE6. Schools are the same.
One point con-support of IE6 is that Microsoft no longer offer support for it, and it is considered a defunct browser, so why should I waste my time catering for it.
It is a little bit of a dilemma. I'd love to hear other peoples responses to this.
One point con-support of IE6 is that
Microsoft no longer offer support for
it, and it is considered a defunct
browser, so why should I waste my time
catering for it.
Because it's not Microsoft you're catering for, or people who consider it a defunct browser, it's people using the browser, aka your customers. By all means, don't take on customers who have a requirement that you support IE6 with websites you produce, that is your chocie. But if you're getting paid for it, I'd hardly call it "wasting my time" =)
For my own sites I do not bother with being pixel perfect and having identical functionality in IE6 but I do like to make sure that the site is accessible and functional at a basic level. That shouldn't be too hard and it'll probably be useful for web crawlers as well.
I don't see an alternative. In fact, I dare say it wasn't very professional of you to put a commercial site up that doesn't support IE6. Your site should work on all browsers - cross browser compatibly is part of our job.
In reply to the comments, here's what I mean when I say professional:
It is expected of you to know IE6 is going to be a problem before you start.
Target supported browsers must be part of the contract. Before working on the site you should ask who will be the target crowd and make that decision together. If you need to support IE6 your cost estimation should be higher.
It is expected of you to at least test the site or all browsers (yes, including IE6, knowing that it isn't quite dead yet - you don't have to like it though).
IE6 doesn't support PNGs, has weird box model (so don't use width+padding), etc etc... Every time I consider using a PNG, I take a note - this wouldn't work in all browsers. You are expected to know that or find it in the test you've made.
Full disclosure - the site doesn't look or behave exactly the same on all browsers? When you present the site, explain how and why, and how it will effect end users. This may sound silly, but if you don't have IE6 in your contract, your client may not be too savvy. Your client is going to find out eventually the site doesn't work on IE6 - most likely when the site breaks for of her friends or clients, making her look bad. That knowledge better come from you.
I agree, making web sites display correctly in IE6 is tiresome. Being a web developer for a multinational pharmaceutical company I would know, they are still required to use IE6.
But there's another point to this. If we, the web developers as a group, continous to cater for IE6 then the large organizations have no reason to upgrade. Are we then responsible for people using IE6?
At our firm we have decided not to support IE6 in the administration part of our CMS, but we do cater for IE6 to the public eye.
The client mentioned earlier runs an old version of our CMS and is so stuck there although we and the administrators are willing to upgrade. In other words: Stuck between a rock and a hard place.
It depends who you expect to use the website.
Some recent figures for use of IE6 in different places make interested reading.
If your client still uses IE6, then you are probably going to have to give in (or convince them of their evil ways). Otherwise it might be worth explaining the numbers involved and the additional cost to cater to them - if it takes x hours of your time, does your client really want to pay for that?
Count yourself lucky you're not trying to cater for the Chinese internet user-base...
I make the site work in IE6, but have a banner that comes down pleading with the user to upgrade to experience the awesomeness of this century.
Example page that shows the banner
My opinion is that the site has to be USABLE.
Eye-candy is good, and should be given to as many users as possible but, the question is: does the gray background of the image render the site impossible to use?
Supposing you have a substantial IE6 user base, are these users really complaining about that?
Or do you have 1 person out of the 100 that use IE6 complaining?
Now people say that the clients pay and you have to do what they say etc etc... Well, it's YOUR role to TEACH the client why IE6 should NOT be supported anymore.
Show them that:
1) the site WORKS (i.e. you can read content, submit forms etc), so the IE6 users will be able to use it
2) you can put some "hints" like "you have a crappy browser, don't complain if websites suck with that" (maybe in a slightly more polite way)
3) show them that even Internet giants dropped support for IE6. Why should you keep it? Do you really want to live in the past?
Depends on your user base and would need to be agreed with your client. For an intranet type application you may be able to avoid it. For public applications - government, banking websites, anything the public may rely on, you need to consider it still.
For more luxury type sites, e.g. 'brochure-ware' for a small business, you may be able to take a call on this, but again depends on your client's requirements - do they want to potentially turn away some business? If you can make it fail gracefully (i.e. still looks ok in IE6, but with less bells and whistles), then you have more chance of selling this.
How much money do you earn from the customers who still use IE6?
How much resistance is there within those companies to upgrade from IE6?
How much money will it cost you to support IE6?
We are software developers. We make tools to make life easier for people ("users").
If a user of your software is using IE6, and you refuse to offer that user support until he/she upgrades to a newer web browser, are you making life easier or harder for them?
I'm actually not asking this question rhetorically, believe it or not. It may be that for you to support an older browser takes away too much of your time, keeping you from developing features that would be of greater benefit to the user.
My point is that you need to ask yourself what is best for the user, not whether catering to someone who's using an old version of a piece of software (who isn't?) is somehow beneath you.
I like this approach: http://morten.dk/blog/ie6-tax-now
Normally I would say that IE6 and IE7 is not supported by default, but the client can pay an extra price for supporting legacy browsers (the website will cost 30-50% more depending on the website requirements).
It might be also a good idea to get information from similar sites. One of our newest deployed site has 2-3% IE visitors (including all IE versions), and the IE6 and IE7 users are below 1%. So we decided not to support IE 6 and 7 at all (we don't test them), and we give full functional support for IE 8 (the site is usable, and looks OK, but it isn't as sexy as in a modern browser with a better CSS3 support, which means that there aren't any gradients or rounded elements). But this site is a little special case.
So I say that analyze what kind of people will visit your site, and make a decision based on that information.
I've never understood the idea that this is some sort of "ethical" issue.
If it's around a client then it's a commercial issue.
If your contract says that the site you've developed will support IE6.0 then yes, you should support it.
If it doesn't it's up to him to work out whether he wishes to pay you more to fix any issues that come up with it.
(If it's not specified then you need to make sure you specify it in your next contract otherwise you're open to requests to support anything your client fancies).
In terms of whether it's worth him supporting it, it will depend on his market. I previously worked for a travel firm whose core client base was people who were aged 40+ which 12 months ago was still registering 30 - 40% IE6.0 usage. In that instance IE6.0 support for their site is critical but obviously each site has a different user demographic and that will dictate your approach.
But an approach based on "principal" is unlikely to be the right way to go, you need to have specific commercial or technical issues which mean that the cost of supporting the browser is greater than the cost of not supporting it.
This is a great discussion. My customers are car dealers and while IE6 useage is declining, it is still 12.5% of my traffic. I have actually seen PC's running Win98 in these stores. Amazing!
We've segmented our catalog product into different interfaces for them to pick from. We're getting ready to launch a new one and we're close to making the decision that it will not support IE6. They can still choose one of the others that still do, and we will continue to support those but not enhance them.
So I can finally embrace sprites and transparencies and ... :)
You can't make a horse drink the water, but you can sure as hell lead him to it. What's the point of going forward in browser technology with advanced engines like Webkit and Gecko, if we still allow stupid, uninformed users to visit our websites in IE6 without any interruption?
Then all web standards are redundant and we can just go ahead and make browser-specific websites, which ultimately will become online applications. I would say, educate your user, after all, if you don't, who is going to do it?
We have made a conscious decision here at our design studio to alert IE6 browser-users that their browser is too old and that they should upgrade. We have not encountered any problems so far.
One should take into account that if you are hired to develop specific IE6 web applications, then you really don't have a choice in the matter, but if you are part of a design studio developing forward moving websites implementing new technologies or advanced Javascript, then I would say forget about IE6.
After all, the internet is full web developer handiwork and if we decide it's over, then the revolution will come.
// edit
If you want to make stuff a little easier for yourself, using CSS, start using BrowserDetect.js CSS browser detection. It's initialised using jQuery and simply adds a browser-specific class to your body tag on load.
In other words, if you're running Safari 5, your body tag will look like this:
<body class="browserSafari browserSafari5">
This enables you to create browser specific CSS styles without any hacking of sorts.
That was my last 2c.
I didn't see this point anywhere above, but I apologize if I missed it.
It's interesting that you say ethical, because I think moving standards for technology forward is one of those responsibilities that we have as consumers and as developers. Moving towards SVG and HTML5 and CSS3 is really good for the industry, because it means more efficiency and a better, faster web.
It may not be best for the client if their site doesn't support IE6, but if developers move on from outdated technologies en masse, it forces the last users of those technologies - in this case, businesses and schools and stegosauri with IE6 - to update their browsers, which is not a negative thing. It's OK to make decisions for the good of the industry as a whole, and we should more often.
It really depends who will be using your app! If your client is the UK gov, then yes, you had better develop for IE6 as it's the only browser in use (due to legacy systems that will ONLY work in IE6)
If on the other hand your client all use Safari, then no you don't have to bother.
Users will not stop using IE6 if all websites still work perfectly with it as they then have no reason to change.
This is bit of a "deadlock" which can only be broken if applications stop supporting IE6
Make the users aware that they are using an unsafe and out-dated software, e.g. with something like:
This webpage will not work (well)
with IE6 because that browser is
insecure and no longer supported
Most of the time you can also convince the customer by explicitely stating how much it will cost to support and maintain the application for an unsupported browser. This will usually be a significant amout for any non-trivial website...
The question really is how much degradation do we make IE6 users tolerate? My feeling is: quite a bit. I'd much rather this minority took the pain instead of holding back everybody else. Since our sites are all (naturally) semantically marked up and pass accessibility guidelines, they will make sense and work just fine with styles and javascript disabled. So the simple answer is to give IE6 users the old Netscape 4 treatment and disable all CSS and js for them.
I would definately suggest customer to upgrade with following points.
Technically no updates are provided by Microsoft for IE6, if they do not upgrade their browser, they should be made aware of all security issues they have left open by not upgrading, such mild threats do work and its right as well. Plus you can certainly recommend firefox, as Microsoft never completely implemented html standard and in large organizations, standard, compliance and security these are always considered as big things and you can certainly point towards them and get your update done.
No.
I have a client that requires for his pages to work in Netscape Navigator because he uses it.
That doesn't mean that I should prepare all my pages for last historical version Netscape Navigator.
I'm writing a web application for public consumption...How do you get over/ deal with the fear of User Input? As a web developer, you know the tricks and holes that exist that can be exploited particularly on the web which are made all the more easier with add-ons like Firebug etc
Sometimes it's so overwhelming you just want to forget the whole deal (does make you appreciate Intranet Development though!)
Sorry if this isn't a question that can be answered simply, but perhaps ideas or strategies that are helpful...Thanks!
One word: server-side validation (ok, that may have been three words).
There's lots of sound advice in other answers, but I'll add a less "programming" answer:
Have a plan for dealing with it.
Be ready for the contingency that malicious users do manage to sneak something past you. Have plans in place to mitigate damage, restore clean and complete data, and communicate with users (and potentially other interested parties such as the issuers of any credit card details you hold) to tell them what's going on. Know how you will detect the breach and close it. Know that key operational and development personnel are reachable, so that a bad guy striking at 5:01pm on the Friday before a public holiday won't get 72+ clear hours before you can go offline let alone start fixing things.
Having plans in place won't help you stop bad user input, but it should help a bit with overcoming your fears.
If its "security" related concerns you need to just push through it, security and exploits are a fact of life in software, and they need to be addressed head-on as part of the development process.
Here are some suggestions:
Keep it in perspective - Security, Exploits and compromises are going to happen to any application which is popular or useful, be prepared for them and expect them to occur
Test it, then test it again - QA, Acceptance testing and sign off should be first class parts of your design and production process, even if you are a one-man shop. Enlist users to test as a dedicated (and vocal) user will be your most useful tool in finding problems
Know your platform - Make sure you know the technology, and hardware you are deploying on. Ensure that relevant patches and security updates are applied
research - look at applications similar to your own and see what issues they experience, surf their forums, read their bug logs etc.
Be realistic - You are not going to be able to fix every bug and close every hole. Pick the most impactful ones and address those
Lots of eyes - Enlist as many people to review your designs and code as possible. This should be in addition to your QA resources
You don't get over it.
Check everything at server side - validate input again, check permissions, etc.
Sanitize all data.
That's very easy to write in bold letter and a little harder to do in practice.
Something I always did was wrap all user strings in an object, something like StringWrapper which forces you to call an encoding method to get the string. In other words, just provide access to s.htmlEncode() s.urlEncode().htmlEncode() etc. Of course you need to get the raw string so you can have a s.rawString() method, but now you have something you can grep for to review all uses of raw strings.
So when you come to 'echo userString' you will get a type error, and you are then reminded to encode/escape the string through the public methods.
Some other general things:
Prefer white-lists over black lists
Don't go overboard with stripping out bad input. I want to be able to use the < character in posts/comments/etc! Just make sure you encode data correctly
Use parameterized SQL queries. If you are SQL escaping user input yourself, you are doing it wrong.
First, I'll try to comfort you a bit by pointing out that it's good to be paranoid. Just as it's good to be a little scared while driving, it's good to be afraid of user input. Assume the worst as much as you can, and you won't be disappointed.
Second, program defensively. Assume any communication you have with the outside world is entirely compromised. Take in only parameters that the user should be able to control. Expose only that data that the user should be able to see.
Sanitize input. Sanitize sanitize sanitize. If it's input that will be displayed on the site (nicknames for a leaderboard, messages on a forum, anything), sanitize it appropriately. If it's input that might be sent to SQL, sanitize that too. In fact, don't even write SQL directly, use an intermediary of some sort.
There's really only one thing you can't defend from if you're using HTTP. If you use a cookie to identify somebody's identity, there's nothing you can do from preventing somebody else in a coffeehouse from sniffing the cookie of somebody else in that coffee house if they're both using the same wireless connection. As long as they're not using a secure connection, nothing can save you from that. Even Gmail isn't safe from that attack. The only thing you can do is make sure an authorization cookie can't last forever, and consider making them re-login before they do something big like change password or buy something.
But don't sweat it. A lot of the security details have been taken care of by whatever system you're building on top of (you ARE building on top of SOMETHING, aren't you? Spring MVC? Rails? Struts? ). It's really not that tough. If there's big money at stake, you can pay a security auditing company to try and break it. If there's not, just try to think of everything reasonable and fix holes when they're found.
But don't stop being paranoid. They're always out to get you. That's just part of being popular.
P.S. One more hint. If you have javascript like this:
if( document.forms["myForm"]["payment"].value < 0 ) {
alert("You must enter a positive number!");
return false;
}
Then you'd sure as hell have code in the backend that goes:
verify( input.payment >= 0 )
"Quote" everything so that it can not have any meaning in the 'target' language: SQL, HTML, JavaScript, etc.
This will get in the way of course, so you have to be careful to identify when this needs special handling, like through administrative privileges to deal with some if the data.
There are multiple types of injection and cross-site scripting (see this earlier answer), but there are defenses against all of them. You'll clearly want to look at stored procedures, white-listing (e.g. for HTML input), and validation, to start.
Beyond that, it's hard to give general advice. Other people have given some good tips, such as always doing server-side validation and researching past attacks.
Be vigilant, but not afraid.
No validation in web-application layer.
All validations and security checks should be done by the domain layer or business layer.
Throw exceptions with valid error messages and let these execptions be caught and processed at presentation layer or web-application.
You can use validation framework
to automate validations with the help
of custom validation attributes.
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=477
There should be some documentation of known exploits for the language/system you're using. I know the Zend PHP Certification covers that issue a bit and you can read the study guide.
Why not hire an expert to audit your applications from time to time? It's a worthwhile investment considering your level of concern.
Our client always say: "Deal with my users as they dont differentiate between the date and text fields!!"
I code in Java, and my code is full of asserts i assume everything is wrong from the client and i check it all at server.
#1 thing for me is to always construct static SQL queries and pass your data as parameters. This limits the quoting issues you have to deal with enormously. See also http://xkcd.com/327/
This also has performance benefits, as you can re-use the prepared queries.
There are actually only 2 things you need to take care with:
Avoid SQL injection. Use parameterized queries to save user-controlled input in database. In Java terms: use PreparedStatement. In PHP terms: use mysql_real_escape_string() or PDO.
Avoid XSS. Escape user-controlled input during display. In Java/JSP terms: use JSTL <c:out>. In PHP terms: use htmlspecialchars().
That's all. You don't need to worry about the format of the data. Just about the way how you handle it.
I dont know what to say. About 3 days ago I released a script to the public. Today I realised, after searching on google that someone had already nulled (removed my protection) and pirated the script.
How do I stop users from pirating the script? It is written in PHP.
Please help or suggest some solutions.
Thank you for your time.
UPDATE By releasing to the public means that I have started selling it to users.
UPDATE My program is priced at only $49. Very reasonable for the functionality it offers. I do not understand how I should stop pirates from pirating my code. The replies which most people have given are rather sarcastic. I was hoping for some good advice. I know there is no silver-bullet. But some techniques which you have used in your PHP programs.
The only real way to prevent piracy is to not give the user the program at all! What I mean by this is have the logic you want to protect remain server side and offer a client interface.
There are a few companies that offer protection services, but these are expensive and can sometimes still be overcome.
If you're worried about this happening again, try obfuscating your code. Here is a free program to do just that on PHP code.
I'm not trying to be sarcastic here: forget about them. Here's my rationale:
You can spend tons of time trying to
prevent pirates from pirating your
stuff, or you can spend the same
amount of time giving your paying
users more functionality.
Extreme copy protection does not give your paying users anything but more
hoops to jump through to use your
application - which might lead them
to get frustrated.
Pirates will pirate your applications
no matter how much time you spend
trying to stop them.
Budget a certain
amount of time to put in basic copy
protection - just enough to keep the
honest people honest.
Most importantly: Don't irritate your paying customers.
They are the ones you need to make
happy.
There's not much you can do.
Be flattered your work was deemed worth the effort!
How do I stop users from pirating the
script?
Do not release sensible source code to the public...
[EDIT] After a few downvotes, I decided to comment on my answer:
Any code that is released public has a chance of being hacked. This is the number one reason why Javascript is not secure. No matter how much you will obfuscate it, compress it or translate it to some random japanese dialect, it is still source code that the user has access to. Hence it should not contain any sensible information such as passwords or such. All sensible data should be stored in the server side where it is kept hidden from the user.
If you are releasing a php framework containing both the server and client code; then you have no way of fully protecting yourself. PHP is, like Javascript, an interpreted language. You may translate it, compress it, or obfuscate it as much as you want, (and it's probably the best thing you can do) you will never fully protect it when released to the public.
Again... If there was a magic way to prevent code from being broken, it would have been known for a long time. No-cd patches / cracks for new games/softwares now are almost released the same day as the softwares themselves. It is, as noted by Paul, a form of flattery for you, even though I understand how sorry you may feel.
There are a few instances where programmers ended up with bullet-proof protection, but it usually involved high-end engineering.
With PHP, you're mostly out of luck. It's an interpreted language, which means that you are essentially forced to give away the source code. Sure, there are obfuscators (tools that "scramble" the source code to make it near impossible to read for humans), but they can be circumvented as well.
There are product like Zend Guard which seem to offer a better level of protection, but from my understanding, your customers need Zend Guard installed as well, which is almost never the case.
There are several methods of handling this:
Offer your product as a service. This means finding appropriate hosting in the cloud, etc. This removes access to your code base, thus preventing direct piracy. Someone can still reverse engineer your stuff, but I'll touch on that later.
Add a unique identifier to each version of the script sold. This can be done automatically, and is great to do with obfuscated code (another, complementing method). This will give you the ability to track whoever pirated your code. If you can track them, you can sue them (or worse).
Pursue legal action. You'll need to know who leaked the code in the first place for this. Their PayPal information or even an IP address should be enough. You go to your lawyer, ask him to get a court order telling PayPal/ISP to release the identity of the thief, and then start tracking them down. If they're located overseas, your only real option is to freeze/appropriate funds from PayPal/credit card. Banks will be sympathetic only if they have a branch in your country (which can be targeted for legal action).
Ignore it, and simply build your business model around the support that you offer.
The sad fact is that information cannot be secured completely. There is no way to prevent a team of Indian programmers from reverse engineering your program. So you just have to be better than them, and constantly improve your product (this is "A Good Thing (TM)", so do it anyways)
Also keep in mind that DRM and other solutions are often controversial, and will reduce your sales (especially among early-adopters). On a personal level, I would suggest viewing this as a compliment. After all, your script was useful enough that someone bothered to pirate it within a week!
PHP is easily decoded, so for people who really want to know, it's easy to find out the source code. However, there are certain obfuscator programs such as this one that'll make your PHP script almost unreadable for those trying to decode it.
What kind of protection did you think you had added to a PHP script, anyway? You should add a line of the form:
if ($pirated)
exit();
and then make it mandatory (in the licence agreement) that users set the $pirated variable accordingly.
Forget trying to prevent it
Go the way of CakePHP (see sidebar on front page) and many other open source projects and ask for donations.
People actually do it!
Contact the pirate and let h{im,er} know that you will be forced to take legal action against them if they do not abide by the license.
I agree with #Michael.
Try ionCube or Zend Guard. They are both commercial offerings, but you say that you are selling your software so it might be worth it. Although nothing is foolproof and can be reverse engineered with enough effort and technical skill, these solutions are probably good enough for the average PHP script vendor.
I agree with Samoz's suggestion to keep the logic server side, however this can often be hard to do. The best strategy is to make the user want to buy it by offering updates automatically to registered users, as well as installation, advice and good support. You are never going to sway people hell bent on pirating, however your goal should be to persuade those who are undecided as to whether to pirate or purchase the script.
Any obfuscation/decryption technique for PHP can be cracked
Jumping in very late to this conversation, but saw this question featured. Nobody mentioned contacting a lawyer and pursuing litigation. You likely saw the script on a server - hosted by a known hosting company - you can probably get a DMCA takedown to have the script removed. If you really press the case, you may be able to sue for damages.
Found this link to assist in going this route:
http://www.keytlaw.com/Copyrights/cheese.htm
You could always pirate it yourself to the internet and hope that any nuller will think "its already been grabbed" so don't bother. But pirate a real buggy version. When users come to you looking for help you'll know they have a pirate version if they question you about specific bugs you purposely added and you can approach them accordingly
If your script won't consume a lot of bandwidth, you could keep your "logic" server-side, as samoz suggested, but if your users won't use it responsively ( a crawler, for example ), this could be trouble.
On the other side, you could become a ninja ...
Attach a copyright notice to it. Some companies will actually care that they're using software properly.
Actually I think it's easier to protect PHP scripts than desktop software, because with latter you never know who is running the cracked copy.
In case of PHP on the other hand, if people run your software on public web servers, you can easily find them and take them down. Just get a lawyer and turn them in to the police. They could also be breaking DMCA laws if they remove your protection so that gives you even more ammunition.
Technical way to protect your code is obfuscation. It basically makes your code unreadable like binaries in compiled languages (like Java). Of course reverse engineering is possible, but needs more work.
In general it's hard to prevent users from stealing code when the program is written in a scripting language and distributed in plain text. I've found that http://feedafever.com/ did a really nice job of being able to sell PHP code but still give the code to users.
But the solution to your problem is very dependent on the domain of your program. Does this script run on the users machine with no internet connection? Or could this be a hosted service?
I'd also suggest looking at some of your favorite software, and seeing how they convinced you to pay for it initially. The issue I find isn't always "how can I prevent my users from stealing my software" but sometimes more "how do I convince my users that it's in their best interests to pay me". Software piracy often comes when your product is overpriced (Ask your friends what they would pay for a software package like the one you are selling, I've found that I have historically overpriced my software by 20%).
Anyway, I hope this helps. I'm glad that you are trying to create software that is useful to users and also not incredibly crippled. I personally of the mind that all software that isn't shrink wrapped or SAAS should be free, but I totally understand that we all need to eat.
The trick is not to try to prevent the piracy (in the long term, this is a losing battle), but to make the legitimate version of your product more accessible and/or more functional than the pirate versions.
"Making it more functional" generally means providing involves additional features or services to registered users, which cannot be replicated for free by the pirates. This may be printed materials (a users manual, a gift voucher, etc), services such as telephone support or help setting the product up, or online extras within the software.
I'll point out that companies such as RedHat are able to make significant amounts of money selling open source software. The software itself is freely available -- you can download it and use it for free without paying RedHat a penny. But people still pay them for it. Why? Because of the extra services they offer.
"Making it more accessible" means making it easier to get your legitimate software than a pirate copy. If someone visits Google looking for your software and the first result is a pirate download site, they'll take the pirate copy. If the first result is your home page, they're more likely to buy it. This is especially important for low-cost software: pirated software may be 'free', but usually it takes more effort to get. If that effort is outweighed by the low cost and lack of effort of simply buying it legitimately, then you've won the battle.
I saw anti-piracy working once only. Quantel EditBox systems (a post-processing video solution), Hardware+Software+Internet solution against Piracy. Workstation only works after checking if the bank received the monthly rent. If not, workstation was locked. Funny days when this happens... (Funny days for me, no work at all... No funny day for the hacker.)
Well, PHP is far away from hardware solutions... so I guess your only real choice is a server side protected against a tiny unsafe client pushing content, as pointed in some answer yet.
piracy != copyright infringement
There are known routes to litigate copyright infringers.
Does it really matter enough to hire a legal team?
Obfuscation do add something. It will not be fun to try to modify your code at least even if they can take the first version of it. In best case they will try to find some open source project that does something similar. Guess this would give you an fast fix at least for your problem?