To learn more about protecting your website, please click here:

http://phpsec.org/projects/guide/2.html

tanks

Serio? u are welcome amigo

Something else that can help to an extent is to validate urls. For instance, my framework does not accept illegality in the urls,
if for instance you want to visit a page like: http://dhtmlkits.com/lagos.php
u can add anything u like to the url e.g. http://dhtmlkits.com/lagos.php?user=myself
but you can never add nonsense like http://dhtmlkits.com/lagos.php?user='
or even use < - escape it if you like, if you add something that is not normally in normal urls you are bounced immediately
to a 404 error page - just in case one stupid module decides to go and echo out the xss attack.

lol

Yeah, sometimes even professional developers forget the basic rules of vulnerability - and even some of my past stuffs are vulnerable to simple sql injection that a primary 1 hacker can use.

lol yea, this ?id=22 always look like bread and butter to toy with.

Wat about encrypting url variables?

Lemme give a very short lesson here again about forms.

Now, i have created a form and i said that only users with a certain privilege can access that form to start with,
so on submit, i say display information about secrets.

Remember, the form will never load for someone without the right privileges to start with. Now, what happens if a script
from elsewhere does a fake submit? Of course, even the referral and other signatures can be forged too.
Well, you must to an extent be able to validate this.

Now, to the use of tokens, token are small bits of information that you stick into your form during generation,
you can for instance say md5(time()) - and save it inside session, and put it in a form. A form that is submitted from elsewhere
without the right tokens is invalid. But this too can be bypassed, sebi na to read the token inside the generated forms to start
with?

These are other things you should worry out. Even simple captchas are bypassed - recaptcha however is much better.

Now, as to encoding url variables? hmmm, what kinda encoding are we talking about here? zend or base64 or md5

If you dont use md5 properly, them go break into your security fairly easily too.


One thing many developers dont do is to verify data types. And i will give an example. Now you have made a site that works like this:

mysite.com/page=1 - this is home page
mysite.com/page=2 - this is about page

you could also use another algorithm like this:
mysite.com/page=page1 - this is home page
mysite.com/page=page2 - this is about page

If you make use of numbers for the page variable, then you should ensure that whatever comes from the browser is the right data type
before even passing it into your database in the first place - so that your database should not swallow poison.

Then your real_escape_string or addslashes and htmlentities may come next.

I will add another one here again.

If you have a website where people register, and you decide to say that,
people should register with usernames of 6 characters - then you should validate
this on the backend too no matter what you do on the frontend.

Nairaland for instance: the registration form does not allow a username of more than
10 characters i.e dhtmlextre - this is 10 characters,

Normally, you should not be able to use in full as a username.
This is not a security breach, but what i am saying is that you should try to validate
stuffs like that properly for consistency.

If you make a field such as email field, try to verify what is in it is at least typed like an email
before you store it away in your database - and store junks.

Spam filter is another thing - dont buy a spam filter in alaba market!

Lets take a look at yet another form scene:

- dual core logs in to his bank online
- He opened several tabs
- Then leaves in hurry, he signed out quite alright
- But he leaves one of the tabs opened, and that
tab contains a form for sending out money.

If you were the one that codes such an app, will you just submit the form like
that? without checking if the owner of the form is still logged in?

These are simple issues that lead to a lot of security breaches.

Consider also file uploads, someone uploads a php script in a photo field,
and gbam - your site turns into a porn site.

Simply because you were very happy that you can finally write code to upload
and did not take the extra time to see what it is that clients are really uploading.


I could go on and on concerning forms, form security is one of the biggest security
threads in the web development world.

All these ones i have said so far are just basics. Because as slr0x and i know, applying
all the above will just reduce and will not totally eliminate hacking down of websites.

@dhtml
uve made valid points. But one'd be amazed at so many factors of vulnerabily. Some could be prevented eg
1. Hiding apache's output signature
2. Removing phpinfo() calls
3. Using escape shellarg() fxn to prevent shell commands from executing.
And so much more,

You can take a look at this thread: http://it.slashdot.org/story/07/01/06/216245/AJAX-May-Be-Considered-Harmful

I have been following up on ajax prototype hijacking for awhile now. And i concurr with those that say that XSS holes
are the problem rather than the 'ajax prototype' in itself.

Most of what is said earlier on are ways to avoid mainly xss attacks and sql injections.

Instinctg, i'll do that stuff for you F.O.C., still busy with lotsa projects. I'll send you a mail when i'm about starting.

My own question @slyr0x is: how secure is encrypting url variables?
I am not saying that you should not do it. But i feel that putting secure data into url is not safe at all,
whether encrypted or not - just my own opinion sha.

Another thing again is that - it is a rather time-consuming process, encoding, decoding. . .i think the focus
should be more of preventing unauthorized access.

@slyrox, i will like to hear your professional views on this.

@sly
tanks so much, i really appreciate. Any technical contributions? Always looking up to ur educative posts

*dhtml:

My own question @slyr0x is: how secure is encrypting url variables?
I am not saying that you should not do it. But i feel that putting secure data into url is not safe at all,
whether encrypted or not - just my own opinion sha.

Another thing again is that - it is a rather time-consuming process, encoding, decoding. . .i think the focus
should be more of preventing unauthorized access.

@slyrox, i will like to hear your professional views on this.

how do u run queries dat need to be passed via url? Eg news.php?id=1
sensitive data esp ones dat have to do with authentition can be passed via sessions (which might also need encryption). Yahoo, google use it.
My background in coldfusion further butresses my point. Encryption is not a sure-footed path to absolute protection, but and added security layer with a little more resource on the server footed path to absolute protection, but and added security layer with a little more resource on the server

That is exactly what i expected. It adds security layer - but it does require some work on the server, and also the developer as well.

In a highly secured application, all these stuffs come in very strongly, but in everyday programming. . . .

U might want to take a look at http://www.phpclasses.org/package/2556-PHP-Encrypt-the-parameters-passed-in-link-URLs.html
in the time being.
Combine that with whatever slyr0x gives you - you should ave a head start

Wat about url-rewrite? An added technique to prevent sql injection?

Caramba! It seems to me that you are looking for the easiest ways out. Unfortunately, there is no easy way out of this.
How long are you gonna keep rewriting your urls? And what happens if you are working on a server that cannot rewrite?

All forms of user-input whether from a form or from a url can cause problems, so you learn to validate as best as you can.
And even with all that, you can still not wave the security guys like slyr0x aside, after you must have done all your
nonsense encoding, then call slyr0x to test things out for you - after you must ave paid him well.

d last thing i do is looking for d easy way out. I dont do url rewrites, just heard it reduces the threat of sql injection.

A url rewrite is very useful for many reason: one of the most important being that it can take actions before your scripts are even loaded - so i think it is useful to an extent.

Nice one dhtml, iWas hoping to post later till you dragged me here .

In my opinion, passing sensitive data thru url variables aint Secure but rily nothing is.

Security comes as a result of the constant countermeasures put in place by you. . .capiche. . .By constant iMean, tis something you need to keep doing, you just nid to follow the trend and apply patches when & where necessary.

Forms may be submitted using one of two methods: GET or POST. If using the GET method, all form elements(names,values) will appear in the query string of the next URL the user sees.

Now tampering with hidden form fields is quite easy, but tampering with query strings is much easier.

You only need to look at the URL in the browser's address bar.

Let's take a look at an ecommerce site that deals with selling recharge pins online.

http://www.example.com/buy.php?phonenumber=08033333333&amount=1000&accnt=123

Whr phonenumber - is d fone no u wantu credit;
Amount - amnt of d card you wantu buy
Accnt - whose accnt to deduct that money from.

So by default, d accnt variable is always set to the user's Id.

Imagine a malicious user doing dis

http://www.example.com/buy.php?phonenumber=08044416523&amount=10000&accnt=555

I tnk dats quite explanatory.

Even passing sessions through the url is wrooooonggg!

It all boils down to input validation tho.

Validate all users input, let's say you ve something like dis

http://example.com/shop.php?id=1

And you knw yo id should accept only integers, den u shld ve something like dis

$id = (int) $_GET ['id'];

Etc,

And also let's say ure using an array

['Home','About','Services','Contact']

Make sure yo code does dis

Search in d array, if it exists, pull the page out, if it doesn't, redirect to the homepage or to an error page.

Or let's say ure pulling yo 'id' from the database, if id corresponds with what's in the database, den get the page, else ERROR(error page/homepage).

That way, u've made sure you aint taking any chances.

Coders overlook lotsa things.


Let's say ure working on a social community and people have to chose their D.O.B. from the drop down menu, make sure user's input is being validated. Cos a malicious user might just with the aid of "Tamper Data", intercept what is being sent to the server, then edit the variable, prolly use a SQL query (Select username,password FROM users--) and we know the story from there .

Conclusion: Always code with the mentality that your users are MALICIOUS.!

That is very good amigo. Hope you guys are learning?
@syl, what of the form method called PUT?