view / update on one page 1

[jjpetrucelli]

i have a system now that is viewable to the public but you can also login, for simplicity lets say the public (non login) can view info and if you login you can update. the system currently has the pages coded twice, once for view and once for update. This can cause problems if you were to change the design, add or drop a column from the website. If you change the graphic or add something to one page you have to go into the other page and change there also. people can forget, there could be a bug on one page and not the other, its not the best for consistency.

Now what would the downfalls of creating one page be? I would guess that you could set variables for things like an update button, or textarea etc, based on your login. This could keep the amount of code down.

Whats the best practice here?

 

[ericbrunson]

I've started using the PEAR HTML/Quickform for stuff like that. It will build your form for you, but if I don't want them to edit it, I simply call $form->freeze() and it makes the fields static and I don't show the Update or Delete buttons.

But, if coded correctly, there shouldn't be any security issues.

 

[Olavxxx]

I will tell you how, but not before tomorrow!
please read about sessions() in the meantime!

I'm doing a header("location: bed");

 

[Olavxxx]

If you use sessions, you can do a check on if the session is set.

if the session is set
show all features
else
show browse mode
end if


eg. you just echo the extra <form> tags, like <input>, etc.

 

[jjpetrucelli]

ok ive done some reading on 'session'. It appears that this can only be used via cookies or url variables. Now I am new to php but neither of these seem like an option. Things are very strict around here in many aspects. That being said i dont think cookies are an option (i.e. we would require a user to accept cookies) and the url variable also doesnt seem like an option, although I am not sure. The site will be utilizing SSL although what stops a user with a particular session id from entering another session id into the url? Unfortunately I am used to working with CF which is almost like a web language . I am sort of stuck 'inside the box'. The way our security was handled was that on every page it called for the security. Users were in a table and it detailed their rights, every time a user went to a page it re-evaluated their rights and sent them to the appropriate page. So I am assuming that in PHP for every page called the DB will still have to check the users rights but this time im thinking of maybe setting a variable and for example ~ if logged in then set varx to '<textarea>' else set varx to <p>. if logged in set vary to 'submit button' esle set vary to 'back button'. Am I on the right track here. Im thinking if i do this there will be only one page and like i mentioned if fields are taken of the page, or realigned, or redesigned in anyway it will be 'universal' for the page?

 

[ascikey]

you have been misinformed the session does not have to be sent via the url and cookies do not have to be used as the session data will be stored in a file on the web server

 

[jjpetrucelli]

well i would have to take the credit for 'misinforming' myself, since i was on the php website, viewing the page on session. I must have misinterpreted. Any suggestions?

 

[ascikey]

Sorry I stand corrected. According to the php web site as you rightly say the browser has to except cookies or the sid has to be passed via the url so I think your only alternatives are to write to a database or text file. Is this possible?

 

[jjpetrucelli]

well as i mentioned, being in the 'box' I am used to calling the db for the users rights, then using if's or case's to decide what to show the user based on the users rights ~ detailed in the db

 

[ingresman]

I think I'm confused here.
The PHP session data is only ever held on the server.
(by default in a text file but you can create your own handler to use any other store such as a database)
The cookie or the URL only ever contain the SID (sessionid) which is used as a key.
If you cant use either you might be able to lash something up by generating a uniqueid() and puttig it in a hidden field in a form. If you do this transmit an md5() hash as well (with a secret extra string) to detect tampering

 

[ericbrunson]

Whether you use sessions or not, whether you use a database as your backing store or something, since http is stateless how are you going to guarantee the authenticity of a connection that has been logged in? Even htaccess authentication can be spoofed as easy as hijacking a session if you can snoop the traffic.

If security is that important you may have to use client certificates to guarantee secure transmission. There may be a way to identify the client by cert within php, but this doesn't mean someone couldn't steal the client cert.

You really need to evaluate your security requirements. If the data is *that* sensitive, it shouldn't even be accessible over the network.

Here's a good article on some of the more basic issues:

http://shiflett.org/articles/the-truth-about-sessions

 

[jjpetrucelli]

that link doesnt seem to be working although I am attempting to check out the articles from shiflett, thanx for the refrence.

Im not sure exactly what to do here, i inherited a system. Now lets say that i wanted to keep as much as possible away from the client, for user friendly purposes. Taking that into account what is the best way to go about this?

All I know is that SSL is required, not even sure how to handle the other aspects, obviously!

 

[jjpetrucelli]

hey, never mind got that link ~ it was me

 

[DRJ478]

Some advise:

In general: I would not mix administrative functions with publicly accessible display functions. You also mentioned SSL, so it appears that you are handling data that is worth protecting in transfer, so it should also be well protected an administrative access.
Creating a one-stop script that displays or updates data seems an invitation for hackers to tinker with. Administrative functions belong into protected areas, behind an elaborate authentication scheme that assures that administrative access is only possible for authorized users. These authorized users can be held to specific requirements, such as cookies need to be enabled etc. and session data can be used. I'd hand out a ticket to them that authenticates against a database and also takes the client's session IP into consideration.

 

[ericbrunson]

session IP can be masked if you are coming from behind a firewall and can be spoofed.

It really depends on how valuable the data is and how far an attacker is willing to go to get it. SSL is not military grade encryption, packets can be snooped, wires can be tapped.

I think using sessions via cookies over SSL with agent fingerprinting and IP tracking is good enough for most applications, it's good enough for Wells Fargo Bank and American Express. It think they have a lot more at stake than any of us do.

The only reasonable scenario with higher security that I can think of is using a VPN to make sure your protected from a compromised router.

 

[jjpetrucelli]

yeah vpn is not an option, and of course with any case the best security is to unplug the server and bury it in concrete. Its all about defining the risks, and evaluating what is acceptable

Sounds like the IP tracking can cause problems if used with a wide audiance - routers, dynamic ip etc...?

But cookies sound much better than URL. Why is URL even listed when it comes to security? Im not sure that I understand that.

Also what is military grade encryption?

and BTW the article sent by ericbruson is a good overview

 

[DRJ478]

URL is porbably listed for reasons of completeness - but as you say, it has no place when it comes to sessions that handle authentication.
The IP tracking is not such a big issue. I work at a major University in the northeast (>30,000 students) and we use an authentication scheme that hands out credentials which are bound to the IP where the authentication originated from. Of course, it is bundled with username and password. The ticket expires when the IP changes - all it does then is require re-authetication with the new IP. As an additional layer for really sensitive data we also require RSA SecurID.
Also, when you say "a wide audience", is the number of people with administrative access really that large? Only admin scripts that manipulate data would require this protection.

 

[jjpetrucelli]

we have sensitive data, our audience spans from coast to coast and deals with many 'different type of people' with various infrastructures and knowledge - from almost non existent to top shelf. public can view table x col1, users with privilege x can view table x and y cols1-4, privelage y can view. sprinkle a little insert here and there. Then theres admins who can insert/update/delete tables x-z, then theres 'super admins' (if you will) that can insert/update/delete table t, etc...

 

[ericbrunson]

Military grade encryption would be something like 3DES using a 2048 bit key. The keysize keeps going up and up with the speed of CPUs and the proliferation of distributed computing.

SSL makes it "more difficult" to eavesdrop on your connection, here's a short paper on the issues of breaking 40/128 bit RSA.

http://www.ripnroll.com/ssl_security.htm

I'm not sure when the paper was written, he talks about breaking a 40 bit key by using 250 computers. This is trivial if you consider the hordes of zombie windoze computers that internet racketeers use for distributed denial of service attacks. If those computers were used to brute force crack an RSA key instead of packet flooding, I think it would pose a serious threat to SSL security.