Re: [PHP] Proposal of DOM non-standard method: DOMDocument::loadCharacterEntitiesFromDtd($path)
Freyjkell wrote: > DOMDocument::loadCharacterEntitiesFromDtd($path); > > I like to load character entities (not whole document type > definition). > Whilst we're on this subject - where do you guys normally load character entities from? I recently ported some stuff from the PHPH4 XSLT implementation (with saxon) to PHP5, and I seem to recall having problems with getting entities defined. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Proposal of DOM non-standard method: DOMDocument::loadCharacterEntitiesFromDtd($path)
DOMDocument::loadCharacterEntitiesFromDtd($path); I like to load character entities (not whole document type definition). When I try to do that by creating my own DTD with only character entities, and setting resolveExternals to true, then DTD parser complains that it didn't occur root definition. The proposed method, if called before DOMDocument::load/loadXML(), would get character entities from DTD (and its modules) and apply them during parsing XML. If called multiply, or if XML contains a DTD reference, entities put before would be overwritten. // I sent this post to php.xml.dev, but I didn't get reply for long time. -- Freyjkell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Proposal of DOM boolean property: DOMDocument::omitXMLDeclaration
(bool) DOMDocument::omitXMLDeclaration; Does not need a comment. Implemented in XSLT. // I sent this post to php.xml.dev, but I didn't get reply for long time. -- Freyjkell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Proposal: New list etiquette/rule
On Thursday 12 December 2002 20:06, DL Neil wrote: > Spam Arrest Sender VerificationYesterday we held an amusing discussion > which highlighted the futility of using (badly implemented) technological > 'solutions' to a social problem... > > Herewith I attach a response received pursuant to a list contribution. Does > this 'gentleman' seriously expect every list contributor to provide him > with a personal service requesting permission to be allowed to post to him? > What happens if dozens of his colleagues join up? BTW I will, happily, for > my hourly fee (minimum charge four hours)! > > Suggest that the list 'rules' be updated to point out that such > requirements are unlikely to be received favorably, so if he wants to join > the community he needs to do 'join' us (not vice-versa). > > NB I know that technically I've broken my/the list's rules by reproducing > this in HTML, and have done so that those who can, are able to see the > stupidity in its full glory/know which service NOT to use... I haven't looked at the spam arrest site, but I'm sure they must provide a whitelisting feature where you can manually add people/lists from whom you definitely want to receive mail. In that case, as always, it's another case of user misconfiguration/ignorance. -- Jason Wong -> Gremlins Associates -> www.gremlins.biz Open Source Software Systems Integrators * Web Design & Hosting * Internet & Intranet Applications Development * /* The bug starts here. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Proposal: New list etiquette/rule
Spam Arrest Sender VerificationYesterday we held an amusing discussion which highlighted the futility of using (badly implemented) technological 'solutions' to a social problem... Herewith I attach a response received pursuant to a list contribution. Does this 'gentleman' seriously expect every list contributor to provide him with a personal service requesting permission to be allowed to post to him? What happens if dozens of his colleagues join up? BTW I will, happily, for my hourly fee (minimum charge four hours)! Suggest that the list 'rules' be updated to point out that such requirements are unlikely to be received favorably, so if he wants to join the community he needs to do 'join' us (not vice-versa). NB I know that technically I've broken my/the list's rules by reproducing this in HTML, and have done so that those who can, are able to see the stupidity in its full glory/know which service NOT to use... Regards, =dn - Original Message - From: Kadir To: [EMAIL PROTECTED] Sent: Thursday, December 12, 2002 11:51 AM Subject: RE: Re: [PHP-DB] Formatting txt from a database (verification) Kadir here, I'm protecting myself from receiving junk mail. Just this once, click the link below so I can receive your emails. You won't have to do this again. http://spamarrest.com/a?33905301:611961 You are receiving this message in response to your email to Kadir, a Spam Arrest customer. Spam Arrest requests that senders verify themselves before their email is delivered. When you click the above link, you will be taken to a page with a graphic on it. Simply read the word in the graphic, type it into the form, and you're verified. You will only need to do this once per Spam Arrest customer.
Re: [PHP] Proposal for securing PHP sessions
I think you are definitely on the right track here, though I unfortunately haven't had time to look at your code (thus, I'm just going by your description). Due to frequent vulnerabilities found in Internet Explorer's cookie handling (versions 4.0 - 6.0 allow anyone to view cookies from any domain, regardless of the cookie's characteristics), cookies should be considered public by any system attempting to be secure. Meaning, if both your key that you describe as well as the session ID are stored in cookies, a compromise of both these cookies opens you up to a presentation attack. This does not require the attacker to sniff the HTTP traffic in any way, so even the use of another security method such as SSL does not prevent this type of attack. Instead, you should consider some sort of combination approach, where you utilize both URL variables and cookies. URL variables are quite exposed (and can be revealed with the Referer HTTP header), so you want to make the exposure of this by itself useless to an attacker. At the same time, you want a cookie compromise to not compromise your entire mechanism. By requiring both types of attacks, you at least make a compromise more difficult and therefore slightly strengthen what you've already got. Hope that helps. Happy hacking. Chris mar tin wrote: >Dear all: > >Until I read the article "PHP Session security" >(http://www.webkreator.com/php/configuration/php-session-security.html) >I haven't noticed how insecure PHP Sessions are. > > > >Basically there're 2 problems: > >*) It's possible to hijack a session if you know the >SID (session id) > > 1) If you're on a shared server (cheap webhosting) >other users can get the SIDs by doing "ls /tmp/sess_*" >(/tmp/ is defined on session.save_path on the config >file, so it may be different). > > 2) When a user clicks on an external link, the >browser sends the REFERER url and sometimes it >contains the SID (if session.use_trans_sid is enabled) > >PHP offers a security measure: with >session.referer_check it will reject SIDs comming from >other referers, but the referer url can be easily >forged. > >*) Users can read session data from the session files, >which are owned by the server process (every user >which has an account on the webserver can read server >owned files) > >(If you're intrested in the subject I would recommend >to read full the article: >http://www.webkreator.com/php/configuration/php-session-security.html) > >I have developed some functions to avoid this >problems. They replace the standard session functions >(using session_set_save_handler), so you only have to >include the file at the beggining of your script and >(afaik) you're safe :) > >This is the idea: > >Apart from the session cookie, I set another one (with >the same name and the string '_sec' appended). On this >cookie I set a random KEY. >The name of the file which contains the session data >is the md5 hash of the SID and the KEY together. This >turns impossible to guess the session id by looking at >the filenames. > >To hide the data inside the file, the serialized >string is crypted using the KEY as password, so nobody >can see the content of your user's sessions. > >You can find the code here: >http://www.n3rds.com.ar/files/docs/php_sessions/sess_handler.txt > >Im looking for suggestions to make it 100% compatible >with the standard session functions, and I would like >to hear some thougts about the idea > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Proposal for securing PHP sessions
Dear all: Until I read the article "PHP Session security" (http://www.webkreator.com/php/configuration/php-session-security.html) I haven't noticed how insecure PHP Sessions are. Basically there're 2 problems: *) It's possible to hijack a session if you know the SID (session id) 1) If you're on a shared server (cheap webhosting) other users can get the SIDs by doing "ls /tmp/sess_*" (/tmp/ is defined on session.save_path on the config file, so it may be different). 2) When a user clicks on an external link, the browser sends the REFERER url and sometimes it contains the SID (if session.use_trans_sid is enabled) PHP offers a security measure: with session.referer_check it will reject SIDs comming from other referers, but the referer url can be easily forged. *) Users can read session data from the session files, which are owned by the server process (every user which has an account on the webserver can read server owned files) (If you're intrested in the subject I would recommend to read full the article: http://www.webkreator.com/php/configuration/php-session-security.html) I have developed some functions to avoid this problems. They replace the standard session functions (using session_set_save_handler), so you only have to include the file at the beggining of your script and (afaik) you're safe :) This is the idea: Apart from the session cookie, I set another one (with the same name and the string '_sec' appended). On this cookie I set a random KEY. The name of the file which contains the session data is the md5 hash of the SID and the KEY together. This turns impossible to guess the session id by looking at the filenames. To hide the data inside the file, the serialized string is crypted using the KEY as password, so nobody can see the content of your user's sessions. You can find the code here: http://www.n3rds.com.ar/files/docs/php_sessions/sess_handler.txt Im looking for suggestions to make it 100% compatible with the standard session functions, and I would like to hear some thougts about the idea Martin Sarsale [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Proposal
I currently thinking on doing some freelance PHP programming and web design for somebody. I have a pretty good idea on how much I will be chargin, however I am looking at putting this in writing. I was wondering if anybody had any example proposals/bids or web liks to where I can find such information so that I can create my own. Thanks in advance. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]