How to find out a website is secure?

Ask your self

1. Did you do everything to prevent SQL injection
2. Do you use id values as indentificators, did you secure option for array exploit
3. Are you using RSS feeds, are they secure
4. Hosting, who is responsible for website security? You or your web hosting company? Are the folder permission set correctly?

That is just few things you should look into...

Take a look here for a couple of small functions that will help you, in terms of handling user input.

Also, if you're passing a variable from $_GET, then you can use a type-finding function to help your security. Eg. if you have something like "?id=53" in your URL, then you can just check it using the isnumeric() function. Then no hackers will have a chance.

Remember, if you have no user input, then you'll be perfectly safe. But if you have input, then remember the number one security rule (well, mine, anyway): you can never trust the user.

hello see this article is really nice:
http://info.ssl.com/article.aspx?id=10068
http://webdesign.about.com/od/ecommerce/a/aa070407.htm
And keep in mind:
->encode and decode your passwords perfectly..
->be careful about using trusted payment gateways...
->be away of sql injections..

Thank you peter_budo, Demiloy and Shanthi for your time.
I shall look into all those security measures now and shall make sure I complete all of them before releasing the site.
If anybody knows some more security measures that are to be taken before launching a website please share them here.
Appreciate your time in advance

Thank you

1. 
   
2. Do you use id values as indentificators, did you secure option for array exploit

   
   Hi peter_budo,

   Can you please tell what are indentificators..

   Thanks in advance

I can not remember exactly what was it but it had something to do with "id" passing values in following format WEB_ADDRESS/page.php?id=32, when adding square brackets [] after "id" will show site structure. I will try to find where I read about it and let you know.

I can not remember exactly what was it but it had something to do with "id" passing values in following format WEB_ADDRESS/page.php?id=32, when adding square brackets [] after "id" will show site structure. I will try to find where I read about it and let you know.

Again, I think if you just check it using is_numeric, you should be fine.

thnx Demiloy & Peter_budo I made use of is_numeric().

Now,
when user manipulates the url like,

when the url is www.example.com/xyz.php/userid=22

how to avoid displaying results when user changes the userid from 22 to someother number in the url.

Basically, my site has a search page, when on submitting the username in search, if username exists then linnk is given.

when clicked ,www.example.com/xyz.php/userid=22 appears in the address bar.

how to avoid displaying results when users manipulates the userid there?

Anyhelp is apreciated.

Thankyou all.

You do not want to keep user identification as part of the URL. Put these data into session.

Also, session variables can be exploited if you are in a shared hosted environment.

Someone with ssh access to the shared server can get a valid session id from where PHP stores them and pretend to be authenticated. A way to work around this is to store the IP address of the user at login, and keep checking it on every page. If the IP address changes during the session, require the user to re-login. (Obviously, don't store it in the session variable, but store it in the database).

BTW, this only applies to if you're using shared hosting.

yes,... scru is damn right...
kavitha,keep that point in your mind...

Also speaking of session exploitation, if you post any user input directly to the webpage, make sure to use htmlentities() to verify that no javascript is being slipped in. This will also ensure that someone can't disrupt your html page structure.

sure Shanthi,Robbob and scru, I shall work on that too.. shall add the logic you mentioned Scru.
Thankyou :)

Odds are, if you are certain that SQL and XSS injections aren't going to happen, you should be fine. There is the chance your server isn't secure, too, but if you aren't hosting yourself, that shouldn't be too big of a threat.

Good luck!

> A way to work around this is to store the IP address of the user at login, and keep checking
> it on every page.

And what are you going to do about users who are behind a common proxy which is almost the case with all corporate organizations. Employees never directly connect to the internet, it's always done via a proxy, so a IP address based solution is as brittle as it gets.

> A way to work around this is to store the IP address of the user at login, and keep checking
> it on every page.

And what are you going to do about users who are behind a common proxy which is almost the case with all corporate organizations. Employees never directly connect to the internet, it's always done via a proxy, so a IP address based solution is as brittle as it gets.

What I have done before is just pull a timestamp and innitially add it to session and database record. The the next page request I pull the timestamp record from the database, compare it with the session, if the two match, pull the most current timestamp, replace the session timestamp and the database timestamp with the most current and allow access. If they don't compare I force a login for that user.

What I have done before is just pull a timestamp and innitially add it to session and database record. The the next page request I pull the timestamp record from the database, compare it with the session, if the two match, pull the most current timestamp, replace the session timestamp and the database timestamp with the most current and allow access. If they don't compare I force a login for that user.

Though it means that for *every* request you end up making an extra database read and write call. Though it might be a really good solution for normal sites, high traffic sites can't afford this overhead. Yes, there has to be a better way of doing it. :-)

The distinct advantage of using mature technologies is that you don't have to worry about such details, you pay for it and you get the service. For e.g. when developing a J2EE application using the IBM stack, a few configuration changes here and there using the administrative console of the Application Server and you are good to go with Single Sign On, Session management and the likes.

Though it might be a really good solution for normal sites, high traffic sites can't afford this overhead.

This is something that I strongly anticipate getting experience with.

hello see this article is really nice:
http://info.ssl.com/article.aspx?id=10068
http://webdesign.about.com/od/ecommerce/a/aa070407.htm
.

Hi Shanthi,

SSl and HTTPS are required for a commericial website where money transactions are made through the site right? How far is it true that non-commercial sites need not have them?

Thanks in advance.