leesiulung
-
Posts
83 -
Joined
-
Last visited
Never
Posts posted by leesiulung
-
-
HTTP request is not Packet.
If you have used telnet or shell account before or even DOD command line
you might be familier with this.
what browser Does
-------------------
It opens a Sockets on port number 80 on http://yourdomain.com
and sends HTTP Request.
HTTP Request is something like this you opened telnet and entered a command on some port
or you opened dos and entered a dos command.
Just Like that Browser sends Some HTTP Comands (Just to make you understand easily I am using 'Commands') 1 by 1 on that port.
I just went with the lingo of prozente, but yes HTTP commands are irrelevant of the communication medium. Hence it can go over mutliple packets or whatever you are using including morse code. if rigged you computer to respond to that.
I was attempting to refer to the fact that only one message goes either way (ignoring packet transmission etc) gets sent out on each page fetch. Meaning the client crafts all the HTTP commands and sends that in one go to the webserver, once the webserver receives the message it returns the requested data (message) in one go to the client. Next request is unaware of previous requests and there is no multiple exchanges of message between client and server in one http session. I hope that is clear enough.
I think this guy is a hacker wanabe!
Why don't you snife the packates and decrypt the SSL.
I'm not a hacker wannabe although I have played around with various exploits and had some fun with that. However, I have and will not conduct any illegal computer activity.
With that said, I think any serious programmer should spend time understanding at least two things:
- software engineering (or design in general)
- good programming practices
- security
A lot of terrible programming occurs because of lack of any or all of the above points. Beginning PHP programmers like myself probably produce very unsecure code due to the nature of PHP as a language and how it is designed. It surprises me that people aren't more interrested in security issues in using sessions as just about any site I visit this days use session cookies or at least cookies.
It seems like at this point the only way to prevent the session cookie from leaking is forcing the visitor to surf over https... Howver, that is not what large sites like amazon.com or ebay.com does it... also it would seem that the people designing the http specs would have thought of this blaringly obvious issue.
-
...
To make the name Identical PHP makes the Session's file name ses_md5($time) as teh time is Unique teh md5 Hash will also be Unique.
And now what we need to do next is to Identify which session Is for Which User and To do that we store the md5 Hashed Part of that File (e.g. md5($time) Part) as Cookie in User's PC. and By default PHP keeps the Cookie var name as PHPSESID
When we are using session_start()
PHP is getting the Hashed part from the Cookie and adding "sess_" with that and accessing the File with that Name and And making an array Variable With name $_SESSION that contains that File's data in an array.
And after that we are using that Array.
I did not know that the Session ID was created from the time and then hashed with MD5. It is unlikely, but possible that two surfers access the site on the exact same time down to the millisecond ending up with identical session names, unless the server is the one creating the session id.
...
GET /files.php HTTP/1.1 Host: www.example.com Cookie: PHPSESSID=10000100101
So this would be sent to the web server, the web server find the base web directory to use for the domain www.example.com from the web servers configuration
...
If you need this to be secure then you will want to use HTTPS as suggested. What this will do is it will use SSL to first initiate a connection to the web server, public key encryption is used so that the key used to encrypt the traffic isn't sent over the line. Once the connection is made with SSL then the HTTP packets will be encrypted so it won't be in plain text. This makes it much more complicated to view the traffic.
Since the session id is sent with every page request and that there is only one packet (with the HTTP request information) sent when each page is requested the whole site has to be surfed on over a SSL connection. Is there any way around this? Someway to manage this?
To clarify during any http request, there is only two packets that go back and forth i.e. the request packet and the response packet. Is this correct? There is no server request for additional information during http connection?
Thanks guys, this is clarifying a lot of things though.
-
The web server gets the cookie form the client's HTTP request just as it gets any other data. Force all HTTP requests to go through https so that any data sent from the client to the server will be encrypted.
I'm not sure I follow you on that. How can I force all HTTP request to go through https? Does that mean that the whole site has to be surfed through https?
I'm actually not sure how the cookie exchange process occurs between server and client. My guess is it goes as follows:
Client: Request a page
Server: if session_start() is on script page, request session id from client
client: sends a session id if it has one, otherwise send some default message
Server: sends the requested page based on session id
Can anyone confirm that? If so, I will be able to make sure all pages that has session_start() force using https.
I really appreciates all the help I have been getting so far. I just want to get to the bottom of this... It is an important topic.
-
check the sessions are NOT stored in a tmp folder that is accessible via a shared folder.
How do one check that the tmp folder is not accessible via a shared folder? That is also fairly unlikely and limited to exploit due to one has to come across a shared folder with tmp folder storing session ids. Interresting thought,... never thought of that.
If you're concerned with someone intercepting and reading http requests / responses, then your best bet is to use a form of public key encryption i.e., SSL.
That is exactly what my concern is. I have SSL enable on the site, but how can I limit the session cookie to only be sent over SSL connection instead of forcing the user to surf the site over SSL at all times.
My guess is that the server only request the session id when session_start() is on the PHP script page being requested by client....
-
Let us assume I don't pass the session id in the URL. It is still possible to sniff the session id when it is being sent by the browser on each request unless is on a secured connection.
I guess I'm looking for someone that can explain how cookies are sent i.e. how the handshaking happens between client browser and server. Concerned about (although somewhat unlikely) sessions ids being sniffed while sent over http.
-
How do one prevent session id's from leaking?
My guess is use session_start() on secured connections (https) only, but the truth is I'm not sure.
Anyone venture to fill me in on this? Anyone working with login/logout type sites should pay attention to this.
-
This probably won't work, but worth a shot.
Try setting all your zones to HIGH and setting the browser to block cookies by using the slider. I don't remember how this is done in IE6, but probably similar to IE7.
-
Well in my quest for shopping carts I ran across osCommerce. Main this thing seems to have everything one would need and best of all it is FREE!
Only concern is that it does not seem SEO friendly. That is a major issue for me. Have anyone used this and can give some input? Good or Bad.... SEO or NOT....
I'm considering using it for my "fun project" of opening a small e-commerce store. I intended to write the thing myself, probably in a long weekend or two since my needs are modest.
However, I'm seriously considering osCommerce instead. I can probably get it up in probably a day.
-
thanks verdicius.
However, I'm still not clear on what happens with a persistent connection. At what point does it free its resources?
It would have been better if they had the database server manage the connection pool instead....
-
Reading the online manual about mysql_pconnect() and mysql_close() I have a problem understanding how one can close a persistent connection? Do one even need to?
Do most people use mysql_connect() or mysql_pconnect (persistent)?
The environment is just shared hosting with GoDaddy....
Also, the anomality with the reference counter and close() is very bad. More info mentioned in the comments of mysql_close() documentation.
-
That's interesting. I tested it on an external server and it worked.
What settings and browser did you use? For instance in IE I had to specifically set to reject all cookies and not just the zones (in fact I don't think the zones matter, but I did it anyhow).
Use a commercial one. Especially since they provide constant updates to the code to accommodate any changes payment gateways/processors make. Not to mention, having to provide support and maintenance.
All my clients are currently using:
http://www.turnkeywebtools.com/products.php?p=sunshop
Written in PHP and loaded with plenty of support for diferent shipping methods and Payment options. They have an online demo you can check here:
http://demos.turnkeywebtools.com/ss4/admin/login.php (Admin)
http://demos.turnkeywebtools.com/ss4/ (Shop)
That is expensive at $250 per year. How easy is the integration process? I'm concerned I spend more time figuring out how to integrate and tweak the cart than actually just building myself. Then again it might have lots more features that I need but did not think of ahead of time.
-
Ok, so it took a while for me to test this session cookie out and I apologize. Anyhow, the results are in and my browser rejected the session cookie. Testing procedure:
1. Set all security zones on browser to High on IE7 (yes, I like IE and no I'm not a MS fanboy)
2. Set browser to reject all cookies
3. Use the following code:
filename: setsession.php
<?php session_start(); $_SESSION['session_exist'] = 'SESSION SET'; echo '<a href="checksession.php">check sessison</a>'; ?>
filename: checksession.php
<?php session_start(); if(isset($_SESSION['session_exist'])) { echo 'Session is SET: ' . $_SESSION['session_exist']; } else { echo 'Session is NOT set'; } ?>Note, that when I tested this on a server running locally on my computer it accepted the session cookie. However, when tested online with server on the internet it rejected the session cookie. I'm not sure why it would accept the cookie on a local instance although it shouldn't even considering it is most likely from a trusted source. However, I haven't bothered to look into this.
[attachment deleted by admin]
-
Have you ever tested this? I did a test by creating a page to store sessin data and cookie data. I then set my browser to not accept any cookies. The cookie data was not saved, but the session data was.
I tested this a long time ago with ColdFusion and setting the browser to reject all cookies. At the time it never found the session. To solve this issue I had to set the session, redirect the page immediately afterward and then check if I could find the session data on the redirected page. If session data was not found, cookies was turned off....
I don't know if this has changed since then, since browsers do different things and implement non-standard things all the time. I will give it another whirl to see what happens and report back.
-
No I don't, because you are confusing session cookies with the $_SESSION data. A session cookie is just a cookie without an expiration set. So the cookie is a "session" cookie because it expires when the session ends. This is different from session data which is stored on the server. The location of the session data is set in the php.ini file under session.save_path
I might have not been clear or specific enough in my language so please excuse me. Unfortunately, English is not my mother tongue. Anhyhow, I do understand that session data is different from session cookies. What I'm saying is that session data is tied to the session cookie. The first time a session is established between a browser and a server, the server sends a "session cookie" to the client browser that gets stored for the duration of the session. Upon each request of a web page from there on by the browser, the session cookie information is forwarded to the server. That is how the server recognizes the client browser. So without the user accepting that session cookie there is as far as I know or can think of right now, how the server will be able to track what request belongs to what session data.
Cookies can also store all the data without storing information in sessions, in which case the data is transmitted to the server on every request. So in essence sessions and cookies accomplish the same thing with minimal difference yet much higher exposure to security risk.
-
You need to define what you mean by "keeping track of". Not sure what you are trying to do with cookies that you couldn't do with session variables - the one exception being saving their cart. BUt, you could simply require them to log in to have the capability of saving cart data. Some sites do one, some the other.
Session variables are almost no different than Cookies other than the data/state you want to save is stored on the server as opposed to the client. In order for the server to identify what data/state belongs to who on the internet, the server sends a cookie (even for a session) to keep track of it. So in essence, using session variables require the user to accept cookies. So what I meant with "keeping track of" is essentially how do I know which session is attached to which user surfing my pages unless cookies are accepted.... See the problem.
if you get a premade one, you have to stick with their setup... their functions and the likes... if you want anything special... thats... too bad...
if you make one, you get full control of what you want it to do, but a) you have to debug yourself, and b) it'd take more time to set up fully
that much said... both routes do work, and both do have (dis)advanatages of their own... if you have more time, i suggest you make it, if you need it up and running ASAP, get a premade one...
I'm trying to figure out reasons for or against each choice. My needs are pretty simple, but would like to give the site the opportunity to evolve with a little forethought. The cart is probably the most complicated task next to security.
All of that said, I like the response I'm getting to this. Although there seems to be many threads about shopping carts.
-
A smart database will cache your query and it will only be costly the first time the query is called. In addition, you can set the field in a session. The cost should be negligable.
Don't really know how to cache queries, does mysql do this automatically or do I have to setup something different?
Please help!
I'm not as familiar with MySQL/PHP, but most databases I encounter, can do stored procedures. In some languages you can also specify to cache the query, for ColdFusion that is with cachedwithin attribute and for Java/JSP you can use PreparedStatements.
Perhaps, somebody else can shed some light on how to do this in PHP/MySQL. I'm sure they have an equivalent or do some Google searches.
Hope this helps...
-
If browsers aren't accepting cookies then use a server side database instead. More secure that way to.
How do you recommend keeping track of user without cookies? Hidden input tags? Session ID's in URL?
I'm not sure I see how is it more secure that way?
-
I finally decided to build my next site in PHP after a lenghty debate with other forum members about some of the shortcommings of PHP. That is for another discussion, but came to the conclusion that it needs a lot of improvement, but had its advantages. I frequently run into PHP sites that needs some work done so I might as well learn it better. Anyhow, my new site will have a shopping cart and I was wondering the following:
1. Which one? Commercial vs. Custom Made!
2. If custom made any suggestions for things to think about before coding? An examples is what to do if browsers do not accepting cookies.
3. If commercial shopping cart, any suggestions and why?
4. Any suggestions on how to implement this a shopping cart?
Currently I'm thinking either implement it using session variables with fall back session id in URL or hidden input tags. Using hidden input tags, of course poses the problem of having to POST to the next page everytime the user navigates to another page. That is a tricky problem. Is there an easier way to do this?
-
This is why there is a PHP manual, it includes information on most. The few that don't have documentation still doesn't leave you in the dark as it's open source so you can look at the source code in order to see what it does. You claim there are too many, well.. it's open source, you don't want so many functions then you can remove some from your installation with some changes and a recompile.
I agree that the PHP documentation is an invaluable source. Without a resource like that I would not even bother to use the language. Looking at the source code is a nice option, but rarely would I want to if ever. It is rarely efficient unless I'm hunting down a bug.
In the cases where a function could open you up to a vulnerability, PHP is pretty good at making a note about this in the documentation and giving recommendations in most cases.
I haven't seen these recommendations, but look forward to seeing them. Hopefully, these are not just recommendations by the user comments that frequently is outdated or just plain wrong only to be corrected by someone else below.
You seem to be basing this on no facts or examples. All functions are grouped by what they do, for instance MySQL functions all listed together here
http://us2.php.net/manual/en/ref.mysql.php
or perhaps you wanted to work with strings but you weren't sure what functions were available. Well there is a string functions page
http://us2.php.net/manual/en/ref.strings.php
or maybe you wanted to deal with images, well there's an image function page and so on..
http://us2.php.net/manual/en/ref.image.php
I must admit that I did not see that there were pages grouped liked that. However, there were no indication on the php.net pages that things were grouped like that. It would have been preferable if they were grouped like packages in Java or header files like C/C++. However, I'm relieved to see that.
On the other side, there is no way to look at a function and see that it belongs to a group of other functions from my experience. For instance, debugging some PHP code I found a function print_r(). How in the heck am I suppose to know from the function name that it prints out variables in human readable form unless I read the documentation. How about print_var or something....
On the functions page is listed the parameter type(s) to be used with it, it's the programmers responsibility to ensure they use the correct type. There are functions for thishttp://us2.php.net/manual/en/ref.var.php
I agree that it is the programmers responsibility to ensure correct type, but as we all know humans are not very good at ensuring anything. There is always some smartass moron that makes a lot of mistakes and will break this rule. On the other hand not type checking also means that there is the risk that I myself make mistakes because I wasn't thinking clearly, just tired or plain stupid that day. Type checking is a must!
PHP is used so much because it is easy to learn, though documentation and because PHP is a glue for combining libraries.
I'm more and more realizing that PHP seem to work with many technologies and seem to have a lot of features supporting different things like image creation etc...
For instance why allow <? ?> and then later realize that it has issues with XML files
Because PHP is so versatile that it was used in ways not though of at the time.
This is an example of things that aren't thought out. One should not introduce new things into a language without thinking it through. The introduction of shortcuts and further expanding the syntax can easily confuse programmers to do incorrect things. For instance a programmer might see it used in sample code and adopt it in an incorrect manner. to me allowing <? ?> suggested that it was ok to use, and never did it occur to me that it might give me issues with XML. However, the gain is 4 characters that I don't have to type every now and then.... hardly seems worth introducing into the language.
You said you've coded in C/C++, so how is it you find the array syntax weird when it's C-like
The syntax for array is wierd in the sense that it allows array declarations as follows:
$a = array ('a' => 'apple', 'b' => 'banana', 'c' => array ('x', 'y', 'z'));
That is not a standard syntax, since it resembles a function array(), yet it has an operator resemblin larger or greater than but does not perform the same task. If memory serves me right another one I remember seeing is where one can grab the keys and the values into two temporary variables for looping.
The bottom line is I find PHP almost like C++ not very well thought out. Although it does have its benefits that I more and more appreciate, yet I still find it needs a lot of improvement. Guess I have to live with it.
-
Honestly, I do not have much experience with PHP or any of the IDE's, but frequently use Dreamweaver 8 (as part of my job) and Eclipse with phpEclipse plug-in (at home). I use Eclipse since I do a lot of development in Java and Eclipse is great for that. It also supports C/C++ and ColdFusion with plug-ins. Best of all, it is FREE and cross platform.
I would as well like to see what others recommend though...
-
I must agree with KeeB, hands down option 1.
A smart database will cache your query and it will only be costly the first time the query is called. In addition, you can set the field in a session. The cost should be negligable.
Do not try to optimize the database with fancy tricks unless you know it will have a significant performance gain. Let the database do what it is intended to do. Optimize only if needed....
-
Backwards compatability issues though... theres just not that much to complain about. A major version upgrade in most languages will require some code reworking. Most of the stuff youve spoken of are (as has been stated) simple configuration settings.
In my experience, rarely do I have to rework any code when a major version upgrade occurs. I have coded in ColdFusion, JSP, C/C++, Java, ASM, VB and even some ASP. The only exception was when Java used the keyword enum to define enumerations. I had picked up this variable name from somebody elses code and had compatibility problems with JDK 1.5. However, the keyword enum apparently was reserved and I never noticed it.
Have you looked at a php.ini file? I'm not sure exactly how many setting there are, but too many? I don't think so. Most of the settings are fine in a default state, if you need extra functionality, they are there to make life easier. Saves having to recompile all the settings in.
As I looked at it, it reminds me of an Apache configuration file and I might have evoked memories of configuring Apache. I still think it is long and most of it as of right now means nothing to me.
I'm really not sure what your getting at here. However, youv'e asked what php programmers think of said issues, and to be honest, I've never had an issue with them. Chances are, if you write clean code, the functionality you use will not become depricated. Things like register_globals where IMO never a good idea, and should never have been introduced.
The problem here is that a language should enforce good programming practices (i.e Java) and if not should at least have a implemented some idea to why those things make sense (i.e C/C++). Problem with PHP so far is it neither enforce good programming nor gives you an idea of why it is there. For instance why allow <? ?> and then later realize that it has issues with XML files or the wierd array syntaxes.
Unfortunately, it looks like I might have to live with PHP as it is seems to be the dominant language for web scripting. Perhaps, someone can point me to an article on good programming practices for PHP.
-
Oddly enough my ;always_populate_raw_post_data = On is commented out in my php.ini residing in C:\Windows folder is commented out, yet it works.
-
You are a genius!!!
The data is right there....
Thank you so much!!!
[SOLVED] Enable PHP error output
in PHP Coding Help
Posted
I'm working on a shared hosting environment where it appears error messages are not displayed. Is there a way to enable this through code?
I do not have access to the control panel or anything of that nature. All I got is a username, password and ftp address.
Help would be appreciated as this is frustrating... not knowing what is wrong.