so i want to try and secure my backend php scripts that handle ajax requests as much as possible. right now, all i've got is a statement checking the HTTP_REFERER variable. for what i've got now, which isn't much, this is fine but i'm trying to figure out the best route once i have a login system.
obviously, i'm looking at using cookies but i've got a few questions. is it possible to set the cookie on the backend script or will it have to be set on the page that the user is loading? then how easy is it to spoof cookie information? because if i will be validating the information in the cookie against information stored in a database before executing a command it seems like it will still be vulnerable to direct access, although a bit tougher to access.
so i guess, is there really anything else i can do besides requiring https?
obviously, i'm looking at using cookies but i've got a few questions. is it possible to set the cookie on the backend script or will it have to be set on the page that the user is loading? then how easy is it to spoof cookie information? because if i will be validating the information in the cookie against information stored in a database before executing a command it seems like it will still be vulnerable to direct access, although a bit tougher to access.
so i guess, is there really anything else i can do besides requiring https?
cookies work like this:
a page sets a cookie by sending the browser a "set cookie" header.
then, for each subsequent request that the browser sends to the specified domain and path before the expiration time, the browser includes the cookie data (name and value pairs) by using a "cookie" header.
a cookie for a given domain can be set by any http response given to the browser from that domain.
setting (spoofing) your own cookies is easy. if it isn't clear, to prevent other people from setting a cookie that grants access/permissions, you need to have information in your cookie that other people don't know (e.g., a passphrase).
unfortunately, if that cookie is intercepted en-route to the destination server, then someone can copy the data, forge their own cookie, and get the same access/permissions.
using a hash (with proprietary salt) on the passwords is a good idea. that way, if the a cookie is intercepted, the passphrase cannot be extracted. the cookie will still be usable, but the user's passphrase will remain unknown (this is nice if a user uses the same password on multiple websites.
if you're gonna hash your passphrases, please use sha-1, not md5. and add some strong proprietary salt to kill off people who might try to take a rainbow table to your implementation.
i'm on ambien, but i think this is all good advice.
i have m.s. visio on my work computer. i'll try to draw something up for you tomorrrow.
best
a page sets a cookie by sending the browser a "set cookie" header.
then, for each subsequent request that the browser sends to the specified domain and path before the expiration time, the browser includes the cookie data (name and value pairs) by using a "cookie" header.
a cookie for a given domain can be set by any http response given to the browser from that domain.
setting (spoofing) your own cookies is easy. if it isn't clear, to prevent other people from setting a cookie that grants access/permissions, you need to have information in your cookie that other people don't know (e.g., a passphrase).
unfortunately, if that cookie is intercepted en-route to the destination server, then someone can copy the data, forge their own cookie, and get the same access/permissions.
using a hash (with proprietary salt) on the passwords is a good idea. that way, if the a cookie is intercepted, the passphrase cannot be extracted. the cookie will still be usable, but the user's passphrase will remain unknown (this is nice if a user uses the same password on multiple websites.
if you're gonna hash your passphrases, please use sha-1, not md5. and add some strong proprietary salt to kill off people who might try to take a rainbow table to your implementation.
i'm on ambien, but i think this is all good advice.
i have m.s. visio on my work computer. i'll try to draw something up for you tomorrrow.
best
http://webdesign.about.com/od/htmltags/p/bltags_keygen.htm
Some folks forget about this guy. Useful sometimes.
Apache sessions are tied to a sessionid on the users host. You can tie the session to an IP, and reduce the expiration time. But there's little more you can do than that. HTTPS is really nice in regards to preventing interception. Use it. Love it.
Some folks forget about this guy. Useful sometimes.
Apache sessions are tied to a sessionid on the users host. You can tie the session to an IP, and reduce the expiration time. But there's little more you can do than that. HTTPS is really nice in regards to preventing interception. Use it. Love it.
i did notice that when you start a session, a cookie is placed on the user, though i'm sad that you can't access the $_SESSION on the backend. the way my one script works is, the user will request info about one user, the script returns some info, the user calls back basically saying "that is correct". now this is when i was hoping to do the check, before the script stores the information in the database but when i try to check the value stored in $_SESSION['variable'] nothing gets returned.
oh well, i guess i'll have to just store it in the cookie.
nny, that keygen stuff is pretty interesting.
http://lists.whatwg.org/pipermail/whatwg-what … chment.txt
oh well, i guess i'll have to just store it in the cookie.
nny, that keygen stuff is pretty interesting.
http://lists.whatwg.org/pipermail/whatwg-what … chment.txt
<keygen> look interesting, all major browsers support it too it seems, except of course ... Internet explorer ... This sort of limits the use ...
Well it's in the HTML5 spec now. So even IE is going to have to adopt it if they plan on you know... being a browser of html.
My babelfish translates "IE is going to adopt it" to "It might be supported in 3 years, and may be bugfree and standard-complaint in another 3".
heh this is why no one uses ie.
s/no one uses ie/40% of traffic uses ie/
> though i'm sad that you can't access the $_SESSION on the backend
what exactly do you mean? you should be able to access it.
what exactly do you mean? you should be able to access it.
yeah only the session ID is stored on the cookie. You can store a ton of session vars that are associated with that id. None of that ends up in the cookie.
well on the php page the user loads, i added
the cookie gets made, and the token gets placed in the database. then on the backend script my if statement that gets run before inserting user data into the database is if($token == $_SESSION['token']) but it would never match. doing an echo on $_SESSION['token'] would return nothing, like the variable wasn't even set.
just to do a test, i put the setting of the $_SESSION['token'] in another php file and included that in both the frontend page and the backend script and it worked. this is leading me to believe that the session scope is limited to the page that it was defined on for some reason.
session_start();
if(!isset($_SESSION['token']){
//make token, set $_SESSION['token'] == token, insert token into database
}
the cookie gets made, and the token gets placed in the database. then on the backend script my if statement that gets run before inserting user data into the database is if($token == $_SESSION['token']) but it would never match. doing an echo on $_SESSION['token'] would return nothing, like the variable wasn't even set.
just to do a test, i put the setting of the $_SESSION['token'] in another php file and included that in both the frontend page and the backend script and it worked. this is leading me to believe that the session scope is limited to the page that it was defined on for some reason.
pull the data out to a regular var. debug.
You should be able to use session variables that are tied to a uses session ID ( via the cookie ).
You should be able to use session variables that are tied to a uses session ID ( via the cookie ).
ahhhh i'm an idiot. didn't have session_start(); on the backend script.
heh that'll get you.
did a decent amount of reading today and man, when you think about it nothing is really that secure. :s
where theres a will, theres a way.
where theres a will, theres a way.
> s/no one uses ie/40% of traffic uses ie/
That may be true. But 40%, (...and even 4%...), are still a lot of people
That may be true. But 40%, (...and even 4%...), are still a lot of people
Indeed.
I am sorry but IE is so behind the times at this point that you really shouldn't be supporting it. People will figure out it's time to stop using it if every site they go to looks as broken as their browser is.
It might work that way for your "hobby" site. It doesn't work that way for your company site. You will miss out on customers and will only succeed in shooting your profits in the foot.
For the same reason you "should" also support $any browser, including screen readers and the like. It might be a little bit of extra effort (and thus money), but it's an investment that will return itself.
For the same reason you "should" also support $any browser, including screen readers and the like. It might be a little bit of extra effort (and thus money), but it's an investment that will return itself.
Yeah, I dunno supporting an IE version of a site is a considerable investment. Alternatively producing a generic one size fits all site is a highly restrictive situation. Either way there is a cost associated with it here.
Personally I'd rather take the "Apple" tm approach here. As a smaller business, I would focus on getting the thing I do, really right. For me that would mean getting the experience right. If I cant' do that on IE, well shit happens. You may be reducing your customer base, but as long as all of your customer base is really happy that can at times be a heck of a lot better than a larger customer base of not entirely satisfied customers.
It's a cost benefit question. I think the specific scenario would dictate a response. But, to say that you "HAVE" to support IE is absurd. There is a cost to doing so, ignoring it would be unwise.
Personally I'd rather take the "Apple" tm approach here. As a smaller business, I would focus on getting the thing I do, really right. For me that would mean getting the experience right. If I cant' do that on IE, well shit happens. You may be reducing your customer base, but as long as all of your customer base is really happy that can at times be a heck of a lot better than a larger customer base of not entirely satisfied customers.
It's a cost benefit question. I think the specific scenario would dictate a response. But, to say that you "HAVE" to support IE is absurd. There is a cost to doing so, ignoring it would be unwise.
Turns out, I ended up not needing any of that stuff. Ended up just using simplexml to get all the info i needed and grabbing it on the fly instead of storing anything since the data could change so frequently.
what i was working on
Eventually I'll be adding the ability to view players backpacks, game stats, etc. but this was all just basically just a learning experience for me. I really had never worked with php or jquery and i've always wanted to learn both.
what i was working on
Eventually I'll be adding the ability to view players backpacks, game stats, etc. but this was all just basically just a learning experience for me. I really had never worked with php or jquery and i've always wanted to learn both.
oops
so i got another quick question, but this time about mysql, well maybe more specifically database structure.
heres the problem:
What I'm attempting to do is a mashup with google maps that will basically plots hikes/trails. My problem is, I am going to require at least a start waypoint, a finish waypoint and 5 other waypoints inbetween, but i want the user to be able to input as many waypoints as they want to get the most detailed route possible. the way I'm thinking about storing the info now would be have a start and end column, then have a middle colum that stores the rest of the waypoints. then when actually using the data, explode it on a , or something.
I think what I want to do would work, but it just seems to me there has to be a more efficient alternative.
heres the problem:
What I'm attempting to do is a mashup with google maps that will basically plots hikes/trails. My problem is, I am going to require at least a start waypoint, a finish waypoint and 5 other waypoints inbetween, but i want the user to be able to input as many waypoints as they want to get the most detailed route possible. the way I'm thinking about storing the info now would be have a start and end column, then have a middle colum that stores the rest of the waypoints. then when actually using the data, explode it on a , or something.
I think what I want to do would work, but it just seems to me there has to be a more efficient alternative.
table `route`
route_id int
name text
table `waypoint`
wpt_id int
route_id int
coords varchar
rdbms
route_id int
name text
table `waypoint`
wpt_id int
route_id int
coords varchar
rdbms
hmmmm thanks larz.
I did some more reading of the google maps api, and i guess the most waypoints that can be submitted is 8, so we'll see how this goes.
I did some more reading of the google maps api, and i guess the most waypoints that can be submitted is 8, so we'll see how this goes.
is there not a difference between a waypoint and a coordinate? i've seen people plot hikes that had far more nodes than 8
no there isn't. all the waypoint is is a lat and lng pair. the reason i said that is when using the directions portion of the API you can only submit a maximum of 8 waypoints (lat lng pairs or addresses). though, i have no reason to worry because *suprise* from reading some more, they have a function that can take as many lat lng pairs as you want and draw the line without sending anything to google.
i've hit a snag. none of the computers available to me seem to be able to load my spreadsheet of wilderness boundary coordinates (500mb worth). sad day :(
haha jesus
yeah it's pretty ridiculous, but it's every single wilderness area in the united states and each wilderness boundary has (it seems) a minimum of ~1000 waypoints. should be interesting to see how well my little falcon handles when serving up the map with all these overlays.
haha yeah, not gonna happen. played around with it all day and i'm gonna have to ditch the wilderness overlays and just stick with map markers and serve up the polylines on an on demand basis. the time i would have to put in converting all the coordinates from screenpoints to lat/long just doesn't make it worth it. there is also the option of serving up each region as a kml file, but as i found out today, those are too iffy to depend on (especially when they are over 100kb in size), plus loading 700 of them just is a waste of bandwidth.
guess it's just gonna have to wait until i can afford an arcgis server. :P
guess it's just gonna have to wait until i can afford an arcgis server. :P
fusion tables ftw!
Why do some people use code like:
echo "<h3 style=\"font-size: 12px; color: #eee;\">".$title."</h3><table style=\"border-collapse: collapse\"><tr><th>header</th><th>anotherheader</th></tr><td>".$somevar."</td><td>".somefunc($anothervar)."</td></tr></table>";
I kid you not, this is the kind of shit I have to deal with at the moment. It is stupid beyond comprehension.
... And to imagine they hired the last guy to clean up stuff :-/ Even stuff he wrote from scratch contains this kind of shit. It's completely unmaintainable shit.
bah.
</rant>
echo "<h3 style=\"font-size: 12px; color: #eee;\">".$title."</h3><table style=\"border-collapse: collapse\"><tr><th>header</th><th>anotherheader</th></tr><td>".$somevar."</td><td>".somefunc($anothervar)."</td></tr></table>";
I kid you not, this is the kind of shit I have to deal with at the moment. It is stupid beyond comprehension.
... And to imagine they hired the last guy to clean up stuff :-/ Even stuff he wrote from scratch contains this kind of shit. It's completely unmaintainable shit.
bah.
</rant>
haha thats what php newbs like myself do. actually i only do that for ajax, would like to get away from it but for the small amounts of data i have no reason to format it in json or xml.
Actually, lots of consultants are known for removing white space on their code...
I know guys who made scripts that would eliminate white space and then proceed to replace variable names with a set of names taken at random from a book of baby names.
The idea is that they can undo what they did easily, and work on the code, but if their client uses another vendor they will be boned.
Ethical no. I wouldn't do it myself. But people do do this sort of thing.
I know guys who made scripts that would eliminate white space and then proceed to replace variable names with a set of names taken at random from a book of baby names.
The idea is that they can undo what they did easily, and work on the code, but if their client uses another vendor they will be boned.
Ethical no. I wouldn't do it myself. But people do do this sort of thing.
Yeah, I've seen that too. But this isn't that. It's just shit code, it's not like *every* line is like that.
The design is also simplistic (simple == good, simplistic == stupid).
The design is also simplistic (simple == good, simplistic == stupid).
meh better simple minded than simpleton attempting to construct a cathedral.
It's like a paper mache cathedral.
Fill it with candy. Hit it with a bat.