Okay, some ground rules. Don't just pass user input directly into SQL queries. Take this line of your code...
Code: Select all
$sql = "SELECT `client`, `deadline`, `detail`, `finished` FROM `jobs` WHERE `id` = " . $_GET['id'] . ";";
If someone browses to the page with
?id=123;DROP TABLE jobs, say goodbye to your jobs table. That's SQL injection and it can do worse. Rails completely bypasses the issue. That line would look like one of the following...
Code: Select all
@job = Job.find(params[:id])
@job = Job.find_by_id(params[:id])
@job = Job.find(:first, :conditions => [ "id = ?", params[:id] ])
@job = Job.find(:first, :conditions => { :id => params[:id] })
They all do the same thing, except the first one will raise an exception if the record is not found. The others will just return nil. First of all, these are much nicer because, apart from being shorter, you don't have to do any further processing. The data is all there in a very useful object, not just some array. More importantly, in all cases, the given user input is sanitised by Rails before being sent to the database. Notice that it is never given directly as part of an SQL string. The user input is always separated.
XSS is a bit harder to explain. The basic rule is don't allow users to add JavaScript ANYWHERE on ANY page. It is easier for them to do this than you might imagine. You know that client name field?
Code: Select all
<td>Client Name: <input type="text" name="client" size="50" maxlength="500" value="<? echo $arr['client'];?>" /></td>
What's to stop them entering
alert("hello");. Harmless enough you might think. But what if they enter
document.write('');. foo.com is a server belonging to the hacker. bar.gif is a 1x1 pixel transparent GIF. document.cookie contains the contents of the cookie belonging to whoever visits that page. Because the image is transparent, you'll never know it's there and the cookie of every user that visits that page will be logged on the attacker's server log. From this, they can determine each user's session ID and hijack their session. If you're an admin and they hijack your session, then they'll be an admin too. Rails makes it easy to avoid this.
Code: Select all
<td>Client Name: <input type="text" name="client" size="50" maxlength="500" value="<%=h @job.client %>" /></td>
See that h? That's what does all the magic. It should actually be h(@job.client) but the above line does the same thing and putting the h off to the side like that looks tidier and it quickly becomes a habit. So what does it do? It escapes all HTML by just replacing a few characters, most crucially with . That'll kill any JavaScript. Why escape all HTML and not just JavaScript? You can do that instead but JavaScript can be included in the most bizarre places. Trying to catch every single catch is extremely dangerous. That is why allowing BB code and textile for user input is much preferred to allowing HTML. You can also avoid XSS by resetting sessions when users log out, timing out sessions when they don't and tying sessions to IP addresses, though the latter has its problems.
I'm too tired to explain CSRF now.
Look it up and also look up what Rails does to prevent it. It's the forgery protection feature.
I'll explain how you should handle passwords tomorrow.