Hidden sessions

[kei_ki7]

i dont have negative intension in my post, its to all readers.

[comando]

how GumSlone said , dont use $_SESSION[] on mobile sites because is not allow by all mobile browsers
Advice:

Try to make the session md5 of user browser and ip and the islogin function will be
function islogin($sid){
$haip=$_SERVER["REMOTE_ADDR"];
$bw=$_SERVER['HTTP_USER_AGENT'];
and then
if(($sid==md5($haip.$ip))

{
is login

}
so if somebody get the session can not enter because must have the same IP and the same BROWSER

I hope you undertand

[amylee]

same IP and the same BROWSER

ip's and browsers can easily be spoofed

[morse]

ip's and browsers can easily be spoofed

IP spoofing ?? spoof A Moroccan or Iranian IP.
I dont think its possible

[ksg91]

how GumSlone said , dont use $_SESSION[] on mobile sites because is not allow by all mobile browsers
Advice:

Try to make the session md5 of user browser and ip and the islogin function will be
function islogin($sid){
$haip=$_SERVER["REMOTE_ADDR"];
$bw=$_SERVER['HTTP_USER_AGENT'];
and then
if(($sid==md5($haip.$ip))

{
is login

}
so if somebody get the session can not enter because must have the same IP and the same BROWSER

I hope you undertand

we may use cookies also to find if this is the same person who logged in.

[djlee]

ip's and browsers can easily be spoofed

ip's and browsers can easily be spoofed

browser.. yes
ip.. no

Its a common misconception that ip spoofing is possible in all situations, in fact in most applications it is impossible, tcp/ip works via a 3 way handshake, this is for a number of reasons not really a security a feature but it is via byproduct just that.

1: Machine A says "hi" to machine B
2. Machine B responds "hi" to machine A
3. Machine A responds "OK im still here, show me the data!" to machine B

Spoof your ip to another IP and you essentially put a new machine into the context

1: Machine A says "hi" to machine B
2. Machine B responds "hi" to machine C
3. Machine A gets nothing, machine B closes connection as its no longer valid, machine C is like WTF!

There are 2 ways of doing ip spoofing, the first is blind spoofing, this is where you establish a connection by pretending to recieve the reply

1: Machine A says "hi" to machine B
2. Machine B responds "hi" to machine C
3. Machine A waits for a second so it knows machine B has sent out its reply and then says "OK im still here, show me the data!" to machine B

This means all data is passed to machine C from machine B, machine A can send data but cant recieve it, in most applications such a thing would be useless. In fact only very few applications do apply for this method (non of which apply to anything anyone here will probably come across in their development career)

The second way is by packet sniffing machine C during the blind spoof, to do this you need to be on some sort of network with the machine IP your spoofing. So if your VERY good and the machine IP your spoofing is in the same street as you AND your both on cable ISP you can hack over the network made by the cable internet infrastruture. This method basically allows you to see the data being sent from machine B as it goes to Machine C so you can respond accordingly. This is even more unlikely to even be attempted than the previous blind spoofing method.

----------

All in all spoofing your IP isnt as easy as people may think (i used to think it was easy too tbh). and im 99.99999% sure no one is gonna care THAT much about a wapsite, if they can spoof ip's and sniff packets then they'd more likely be looking for their nieghbours bank details or paypal password than trying to login to their neighbours wapsite account

HOWEVER, i do agree with amy that an IP should never be relied on for authentication, or atleast not sole authentication (in this instance it becomes sole authentication as i said browsers can be spoofed very easily, in fact firefox has a certified plugin extension for browser spoofing)


----------

as for morses response.. if you can spoof an IP then it being moroccan or iranian wouldnt make a little bit of a difference

@ksg91: if you mean use the existence of cookies for seeing if they are logged in then thats even worse, cookies are a plaintext file and can be written easily in notepad by any n00b. always use a one way hashing algorithm to hide plaintext stuff that u use for session auth and always use a number of things to valid a user, this should include as many non user accessible things as possible (i.e. using a subdomain for login and authentication and you CAN use the IP as one way of validating the user session since its so hard to spoof, but dont rely on the IP solely, you never know what the real user is running (maybe they run a proxy without even knowing it))

[ori]

most sites like mine are high in xhtml/css so any non cookie browsers wouldnt handle the file sizes for each page so then using cookies isnt so bad only thing that is hard is telling them it isnt compatible i tried that and every1 got the msg till they hit reload something about setting the session cant be read at same time so a reload is required

[morse]

as for morses response.. if you can spoof an IP then it being moroccan or iranian wouldnt make a little bit of a difference

I myself thought that ip spoofing was not possible but it is very much a reality for those wap sites which only depend upon getenv('REMOTE_ADDR') data. The data collected against $_SERVER["REMOTE_ADDR"] is considerably more reliable than the previous one.
yet still $_SERVER data is something sent by the user knowingly or unknowingly, this data can be manipulated, because at the end its the users systems decision on the type of data that needs to be sent. All that the receiving server can do is collect the data, there is no way to verify it.

[djlee]

ah yes of course but the users system doesnt send their IP address per se, its the tcp packet builder, this means you first need to understand low level programming and everything about a tcp session e.c.t., that just about cuts out 99% of the people who would ever wanna attack your wap site. the remaining 1% then need to create a data packet editor that runs autonomously and futher more for it to be of much use they need some sort of network layer access to the machine ip there spoofing which then turns the success of an exploit from that 1% into a lottery as they have to hope and pray that they are (for all intent and purposes) living next door to the wap site owner they are trying to annoy.

and as i said, the reciever server verifies the IP via the 3 way handshake. this isnt a fool proof security, but it wasnt meant as a security feature but it causes malicious users a big headache as a by product and seriously limits the possibility of exploitation.

so as i said before, use IP for authentication, its a good idea if your application and target audience allows for this security feature (obviously if your target audience has an IP forced on them by their ISP every few minutes then there ip is susceptable to change so the IP is of no value to you - since i aint 100% sure how foriegn mobile isp's work i cant comment) however do not use it as sole authentication, make sure you have other secure authetication keys and procedures (simply because IP's can be shared unknowingly, if your on an AOL like network and so is a member and by some random chance they get your previous IP while your in bed and they happen to be using the latest firefox build the same as you they could get your session automatically)

On that note of the firefox browser thing, if your gonna do browser authentication as a low security, i'll add it for the sake of it, it can only be more secure by having it rather than not after thought... why not use minefield aka the nightly build of firefox (aka firefox beta) or simply use a special user agent string on your website (ive done this before, where ive made staff of a website have to use a user agent string containing a secure auth passkey to get staff permissions, otherwise there account is limited during login)

So theres another idea for security, just dont display the browsers of staff or dont display browsers at all (theres not much point to it) and a passkey based user agent check system could be a good addon to your sites auth system. The possibilities of security are only limited by your imagination

[CreativityKills]

@ori. . .Use a front controller, what ur guests see first. In d page add only

setcookie('cookie_enabled','enabled',time() + (30*24*60*60))
header('Location: index.php?action=guest');

that way d user wdnt evn notice the redirect
then check for cookies if nt set, warn user else cont.

[ori]

i have a location header already (wapdesire.com goes to wapdesire.com/?act=index) and session_start and the code i used was before it but still user has to reload to get rid the error