[PHP] Re: Security/Development Question
On Wed, 28 Apr 2010 16:54:56 -0400, David Stoltz wrote: [...] We recently have added a very small web application that is vendor supported. They said it's not working, so I investigated. I found that our software protection was blocking their pages because they are actually passing entire SQL queries in their form POSTs. Now, the app is SSL protected, and they claim the queries are not executed - only inserted into the database to be used later. They also said it's protected by the ASP.NET framework authentication [...] Unless they're storing the SQL queries so that they can show them later on, e.g. as text in a forum post, I think you have a major WTF on your hands! Please submit here! http://thedailywtf.com/Contact.aspx :) -- Ross McKay, Toronto, NSW Australia The chief cause of problems is solutions -Eric Sevareid -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security/Development Question
On Thu, 2010-04-29 at 08:49 +1000, Ross McKay wrote: On Wed, 28 Apr 2010 16:54:56 -0400, David Stoltz wrote: [...] We recently have added a very small web application that is vendor supported. They said it's not working, so I investigated. I found that our software protection was blocking their pages because they are actually passing entire SQL queries in their form POSTs. Now, the app is SSL protected, and they claim the queries are not executed - only inserted into the database to be used later. They also said it's protected by the ASP.NET framework authentication [...] Unless they're storing the SQL queries so that they can show them later on, e.g. as text in a forum post, I think you have a major WTF on your hands! Please submit here! http://thedailywtf.com/Contact.aspx :) -- Ross McKay, Toronto, NSW Australia The chief cause of problems is solutions -Eric Sevareid You could always try crafting your own query and attempt to insert something of your own. If they complain after that you've broke their system, you'll be able to tell them that it really wasn't that secure in the first place. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Re: Security Concerns with Uploaded Images:
Use the unix command file to determiner what file you have. I have had the same problem... Don't depend on it. graphic.php GIF89 ?php do_bad_stuff(); ? ANY_GIF_FOOTERS_HERE should according to file be a gif, but contains embedded php. Many thanks! Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Concerns with Uploaded Images:
At 9:45 AM +0100 5/23/06, Rory Browne wrote: Use the unix command file to determiner what file you have. I have had the same problem... Don't depend on it. graphic.php GIF89 ?php do_bad_stuff(); ? ANY_GIF_FOOTERS_HERE should according to file be a gif, but contains embedded php. Rory: I'm not disagreeing with you, but how would that work? The file would still have a suffix of .gif and as such wouldn't be recognized as code to execute. For example, I can place php code within a html document and it will not run because the document has a .html suffix -- unless I indicate such in my .htaccess. So, how does placing ?php do_bad_stuff(); ? within any image cause problems? However, if the problem is real, then why not just resample or alter the image in some fashion? Surely, that would cause any embedded code to not run properly, right? Thanks. tedd -- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Concerns with Uploaded Images:
On Tue, May 23, 2006 3:45 am, Rory Browne wrote: Use the unix command file to determiner what file you have. I have had the same problem... Don't depend on it. http://php.net/getimagesize would be slightly better, as it tries to dig out width/height and number of colors for any given format, plus other fun stuff for some formats. So they'd have to hack MORE of a file and make it look kosher enough to fool that... You STILL ought to put the images OUTSIDE the webtree and use PHP to readfile them so they can never get executed by remote visitor, imho. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Concerns with Uploaded Images:
On Tue, May 23, 2006 9:52 am, tedd wrote: At 9:45 AM +0100 5/23/06, Rory Browne wrote: I'm not disagreeing with you, but how would that work? The file would still have a suffix of .gif and as such wouldn't be recognized as code to execute. Unless you have ANOTHER bug somewhere in those million lines of PHP code... Which might maybe let you eval() that, or manage to include it or... Why risk it? Defense in depth. It's not like a call to http://getimagesize is gonna kill you. Even moving the image out of web tree and using readfile is fine for all but the busiest servers. [shrug] I don't understand why people are so resistant to something so simple that adds a layer of defense. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Concerns with Uploaded Images:
At 4:34 PM -0500 5/23/06, Richard Lynch wrote: On Tue, May 23, 2006 9:52 am, tedd wrote: At 9:45 AM +0100 5/23/06, Rory Browne wrote: I'm not disagreeing with you, but how would that work? The file would still have a suffix of .gif and as such wouldn't be recognized as code to execute. Unless you have ANOTHER bug somewhere in those million lines of PHP code... Which might maybe let you eval() that, or manage to include it or... Why risk it? Defense in depth. It's not like a call to http://getimagesize is gonna kill you. Even moving the image out of web tree and using readfile is fine for all but the busiest servers. [shrug] I don't understand why people are so resistant to something so simple that adds a layer of defense. Again, I'm not disagreeing with anyone! Instead I'm simply trying to understand how this might work. Understanding a risk is one step closer to providing a proper defense. Just placing an additional step is not necessary adding another layer of defense and in fact goes against the Simple is Beautiful security level that Chris Shifett addresses in his Essential PHP security book. As for using eval(), that function ranks number one on his list to pay the most attention to with regard to security. I hope that no programmer would use an evalu() on an uploaded image -- but, that might be a way to make an image with embedded code do bad things. However, the programmer would have to be an accomplice in the attack by using eval() incorrectly. In the past, I have used headers of jpg files to store information -- there's a lots of unused space there -- however, at some point, the program that deals with the image has to switch from this is an image to this is an executable piece of code for this to work. I'm trying to understand how that would happen. If this is something that is real, then I am also suggesting that doing something with the image should screw-up any embedded code. But, before providing a defense, one should understand the threat. My $0.02. tedd -- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Security Concerns with Uploaded Images:
Am 2006-05-14 00:11:09, schrieb Nick Wilson: Hi all, are there any security concerns with uploaded images? My thought is that it wouldnt be too hard to have some kind of script masquerade as a gif file, and perhaps cause damage. I cant find anyway to check a file really is a gif/png/jpg (i assume the mimetype available in $_FILES could be spoofed). Use the unix command file to determiner what file you have. I have had the same problem... Many thanks! Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: security of uploaded gif files
James Benson wrote: Even if you can embed PHP in a GIF it would still need to be executed by PHP as PHP code, would PHP actually execute that file when it looks like an image, I would think PHP would output an error? More importantly though, you should be checking the file extension of uploaded files to make sure it is only a .gif James jonathan wrote: what is the best way to prevent malicious code from being uploaded via a .gif file? A friend showed me how php could be embedded within the .gif file. Does this problem also exist for .jpeg's? thanks, jon It is possible for example to use php for showing images like fopen and print a random image file. so opening the .php file will show you a random image. But if the server isnt set to parse other files than PHP you wont be able to execute code. But when server is set so, yes its possible. Thats why checking the file for php alike contents could be useful. I thought there was something like a de-evaluate PHP function that rips off every php code of a textfile/sended text by form or else. That could be useful too. Greets Barry -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: security of uploaded gif files
Even if you can embed PHP in a GIF it would still need to be executed by PHP as PHP code, would PHP actually execute that file when it looks like an image, I would think PHP would output an error? More importantly though, you should be checking the file extension of uploaded files to make sure it is only a .gif James jonathan wrote: what is the best way to prevent malicious code from being uploaded via a .gif file? A friend showed me how php could be embedded within the .gif file. Does this problem also exist for .jpeg's? thanks, jon -- - http://www.ciwcertified.com - Master CIW Designer http://www.zend.com - Zend Certified Engineer http://www.jamesbenson.co.uk - -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security of uploaded gif files
There's a couple of things a person can do. 1. check for .gif extention 2. see if exif_imagetype() returns type IMAGETYPE_GIF 3. see if getimagesize() returns reasonable values and not FALSE 4. check the file content for binary vs text content Gerry -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: security of uploaded gif files
Hi, James. James Benson wrote: Even if you can embed PHP in a GIF it would still need to be executed by PHP as PHP code, would PHP actually execute that file when it looks like an image, I would think PHP would output an error? Unless you include/require or eval() its content, PHP won't execute it. More importantly though, you should be checking the file extension of uploaded files to make sure it is only a .gif I can make a javascript file with a .gif extension, actually. Take a look at exif_imagetype(). Regards. -- Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security of uploaded gif files
Hi, Gerry. Gerry Danen wrote: There's a couple of things a person can do. 1. check for .gif extention 2. see if exif_imagetype() returns type IMAGETYPE_GIF 3. see if getimagesize() returns reasonable values and not FALSE 4. check the file content for binary vs text content It's enough to know whether it's an image and has a reasonable size. What if there is no .gif extension? Rename the file. I think the last step makes no sense. Regards. -- Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
Richard Lynch wrote: On Thu, November 10, 2005 10:11 am, Jochem Maas wrote: rant mode=troll sarcasm=true anger=+3 replies=duck ... or put another way - is there a good reason why the web should be any less discriminating than the rest of society. Yes. It's the WORLD WIDE WEB. shucks, now your getting all pedantic. I really don't think that a few words and well meant principles should be getting in the way of world-domination and/or global-brainwashing aspirations of a couple of media-cartels. ;-) I mean, it's all very well to discriminate against those people way far away whom you will never see in the first place, but they're not any farther away any more, are they? :-^ [tongue firmly planted in cheek, folks!] And if you are a large corporation, you very well may be subject to laws with significant risks attached ($$$) for not being accessible. Google for Olympic Committee blind user Australia big fine for more on that topic. That alone makes it worth considering. Probably the best reason not to use CAPTCHA is that it can already be bypassed by OCR in most cases by a determined person. (Google for it) That means that within a very short period of time, script kiddies and web-POST-spammers [*] will have OCR anti-CAPTCHA technology rolled into their tool-kits. Another very good reason is that even normal users have a not-so-good experience with the damn things. I've gotten way too many indecipherable images and had to click multiple times to get one that was usuable in a single session for some stupid forum post I wanted to contribute. Not my idea of a pleasant web-surfing experience. Certainly not something that makes me want to contribute more to that site. I slapped a CAPTCHA (bad, home-rolled) into a guestbook on a site that had been targetted and was getting hundreds of junk posts a day -- but it's not something I deploy as a matter of course. And I don't expect it to survive more than a year before I have to just get rid of the guestbook. (Assuming the client keeps the site up at all, which is under review.) * So, is there a term for the web moral-equivalent of spammer? Those link-farm visitors who clutter up your site. blammers, perhaps? (blog-spammers). blammer just doesn't sound evil enough ;-). for the rest, good stuff, as usual, Richard :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
Hello. Richard Lynch wrote: On Thu, November 10, 2005 10:45 am, Gustavo Narea wrote: CAPTCHA tests are indispensables. The problem comes when you *only* use visual tests (such as visual turing numbers). If you need CAPTCHA tests, you may use them both visuals and audibles. This is a good example: https://www.e-gold.com/acct/login.html So the user who is both blind AND deaf? Or the blind user who is at a library computer with no audio output? You may find many possible solutions on the web-page I suggested. For example: Logic puzzles http://www.w3.org/TR/2003/WD-turingtest-20031105/#logic. As I said previously, It depends on the target of your website. For instance, if your website is for web designers, you may only need to use visual turing numbers: They must have a user agent which is able to process images and I cannot imagine a blind web designer. On the other hand, if your website is for programmers, you may want to know that programmers can be blind (although you won't take this into account): http://www.blindprogramming.com I saw some research where out of four people with normal hearing, all four were unable to distinguish the crappy audio output into the correct word and use a site. Granted, a very small sample, and the audio from the test site may well have been at the low end of the spectrum for quality. But it was a real site, and these were just regular people roped in for a test of the audio's usefulness. As cool as CAPTCHA seems at first, I don't think it's going to be a long-term solution. In the meantime, I think It's the best we can do. Best regards. -- Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
Hello. Richard Lynch wrote: On Thu, November 10, 2005 10:11 am, Jochem Maas wrote: rant mode=troll sarcasm=true anger=+3 replies=duck ... or put another way - is there a good reason why the web should be any less discriminating than the rest of society. Yes. It's the WORLD WIDE WEB. I mean, it's all very well to discriminate against those people way far away whom you will never see in the first place, but they're not any farther away any more, are they? :-^ [tongue firmly planted in cheek, folks!] Yes, I agree with you here. And if you are a large corporation, you very well may be subject to laws with significant risks attached ($$$) for not being accessible. Google for Olympic Committee blind user Australia big fine for more on that topic. That alone makes it worth considering. But it depends on the country. It should be something international. At least in Venezuela, It isn't so. Another very good reason is that even normal users have a not-so-good experience with the damn things. I agree with you. On the other hand, in many sites, visual turing numbers are very hard to understand. Regards. -- Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
Gustavo Narea wrote: Hello. [snip] As I said previously, It depends on the target of your website. For instance, if your website is for web designers, you may only need to use visual turing numbers: They must have a user agent which is able to process images and I cannot imagine a blind web designer. Well, that's debatable, even among the designers who have use of their eyes. ;) But all kidding aside, I have met one and I'm sure that there are others. Who better to design an accessible site than a designer who experiences the same difficulties as other impaired web surfers. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
On Fri, November 11, 2005 8:47 am, Gustavo Narea wrote: On the other hand, if your website is for programmers, you may want to know that programmers can be blind (although you won't take this into account): http://www.blindprogramming.com What I found most interesting about this site: PHP's total presence there is one (1) link to a site with one (1) on-line tutorial from 2002... Which, as far as I can tell, is not particularly enhanced for the vision-impaired. Hopefully this is not actually an authoritative reference. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Richard Lynch wrote: On Thu, November 10, 2005 3:29 pm, GamblerZG wrote: IMO, the best way is to re-generate SIDs on each request, but such method will decrease perfomance of a script. But if Cookies are off, you just destroyed their Back button in their browser, which should be a crime. Call me evil, but I prefer not to use GET-based sessions (after seing at least 3 websites hacked because of that stuff), so users without cookies can't login anyway. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
rant mode=troll sarcasm=true anger=+3 replies=duck this email contains swearing so that the sensitive amongst you will be spared what I have to say (assuming you have a stupid 'Im a sensitive person, don't expose me to bad language' mail filter) Gustavo Narea wrote: Hello, Clive. Depending on the target of your website, you shall need to keep in mind the (in)accessibility of this kind of tests: http://www.w3.org/TR/2003/WD-turingtest-20031105/ right and almost 3 people on the planet care in practice. besides the chances are the blind person in question will not be able to navigate through your sea of nested tables. (have you ever heard a screen reader walking thru 5 level of tabel nesting so that you can be told of the lovely logo image that the nested tables are apparently positioning ... fantastic oh any then there is the problem of inaccesibility of mailboxes (because it's full, overloaded, etc) because every spammer and his dog can write an automated mailing script that uses your webform if you don't stick some sort of CAPTCHA in there... the most inaccessible on the web currently is the 'look how clever we are' language and document structures used through out the W3C site - bloody impenetrable. pot calling the kettle black so what if every user agent under the sun can 'read' the W3C site - *I* can't read it, fat chance my browser will be able to explain it to me. given that 9 out of 10 government buildings worldwide are not even accessible by wheelchair users (I didn't do the research but I'm willing to put some money on it) worrying about inaccessible webforms is maybe a little premature. - and given that we, in the west (at the least - I don't believe asians, arabs, whatever are any nicer) are a bunch of body facist hate mongerers - your television and billboards are telling you that if you have a disability (that includes being ugly) then you should be figuring out how to get the f*** off our Calvin Klein planet or put another way - is there a good reason why the web should be any less discriminating than the rest of society. rant By the way, AFAIK they are also known as turing numbers. Regards. Clive wrote: Hi does any one have a class/function to generate those security code images. Yhe ones that you see on website that you must enter to submit a form thanks clive -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
Hello. CAPTCHA tests are indispensables. The problem comes when you *only* use visual tests (such as visual turing numbers). If you need CAPTCHA tests, you may use them both visuals and audibles. This is a good example: https://www.e-gold.com/acct/login.html Regards. Jochem Maas wrote: rant mode=troll sarcasm=true anger=+3 replies=duck this email contains swearing so that the sensitive amongst you will be spared what I have to say (assuming you have a stupid 'Im a sensitive person, don't expose me to bad language' mail filter) Gustavo Narea wrote: Hello, Clive. Depending on the target of your website, you shall need to keep in mind the (in)accessibility of this kind of tests: http://www.w3.org/TR/2003/WD-turingtest-20031105/ right and almost 3 people on the planet care in practice. besides the chances are the blind person in question will not be able to navigate through your sea of nested tables. (have you ever heard a screen reader walking thru 5 level of tabel nesting so that you can be told of the lovely logo image that the nested tables are apparently positioning ... fantastic oh any then there is the problem of inaccesibility of mailboxes (because it's full, overloaded, etc) because every spammer and his dog can write an automated mailing script that uses your webform if you don't stick some sort of CAPTCHA in there... the most inaccessible on the web currently is the 'look how clever we are' language and document structures used through out the W3C site - bloody impenetrable. pot calling the kettle black so what if every user agent under the sun can 'read' the W3C site - *I* can't read it, fat chance my browser will be able to explain it to me. given that 9 out of 10 government buildings worldwide are not even accessible by wheelchair users (I didn't do the research but I'm willing to put some money on it) worrying about inaccessible webforms is maybe a little premature. - and given that we, in the west (at the least - I don't believe asians, arabs, whatever are any nicer) are a bunch of body facist hate mongerers - your television and billboards are telling you that if you have a disability (that includes being ugly) then you should be figuring out how to get the f*** off our Calvin Klein planet or put another way - is there a good reason why the web should be any less discriminating than the rest of society. rant By the way, AFAIK they are also known as turing numbers. Regards. Clive wrote: Hi does any one have a class/function to generate those security code images. Yhe ones that you see on website that you must enter to submit a form thanks clive -- Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Richard Lynch wrote: IP is useless for identification or authentication of the general web-surfer: Users behind firwalls will all appear to be from one (1) IP AOL users change IPs faster than drummers change underwear I think it's still reasonable to restrict a session to a single IP. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
GamblerZG wrote: I think it's still reasonable to restrict a session to a single IP. No, it's not, for all of the reasons Richard mentioned and more. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
On Thu, November 10, 2005 1:08 pm, GamblerZG wrote: Richard Lynch wrote: IP is useless for identification or authentication of the general web-surfer: Users behind firwalls will all appear to be from one (1) IP AOL users change IPs faster than drummers change underwear I think it's still reasonable to restrict a session to a single IP. To be more precise: Drummers do not typically change their underwear in a single [recording] session. AOL users WILL change their IP in a single [web-surfing] session. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Chris Shiflett wrote: GamblerZG wrote: I think it's still reasonable to restrict a session to a single IP. No, it's not, for all of the reasons Richard mentioned and more. I agree that using only IP to identify session is bad. Using only SID is ok. Using SIDs that are tied to a single IP is even _more secure_, since the possible attacker would need to have exactly the same IP as a victim of session hijacking. This comes at a price of a small inconvinience for dial-up users (since they would need to login on each reconnect), but I think such price it reasonable. IMO, the best way is to re-generate SIDs on each request, but such method will decrease perfomance of a script. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
On Thu, November 10, 2005 10:11 am, Jochem Maas wrote: rant mode=troll sarcasm=true anger=+3 replies=duck ... or put another way - is there a good reason why the web should be any less discriminating than the rest of society. Yes. It's the WORLD WIDE WEB. I mean, it's all very well to discriminate against those people way far away whom you will never see in the first place, but they're not any farther away any more, are they? :-^ [tongue firmly planted in cheek, folks!] And if you are a large corporation, you very well may be subject to laws with significant risks attached ($$$) for not being accessible. Google for Olympic Committee blind user Australia big fine for more on that topic. That alone makes it worth considering. Probably the best reason not to use CAPTCHA is that it can already be bypassed by OCR in most cases by a determined person. (Google for it) That means that within a very short period of time, script kiddies and web-POST-spammers [*] will have OCR anti-CAPTCHA technology rolled into their tool-kits. Another very good reason is that even normal users have a not-so-good experience with the damn things. I've gotten way too many indecipherable images and had to click multiple times to get one that was usuable in a single session for some stupid forum post I wanted to contribute. Not my idea of a pleasant web-surfing experience. Certainly not something that makes me want to contribute more to that site. I slapped a CAPTCHA (bad, home-rolled) into a guestbook on a site that had been targetted and was getting hundreds of junk posts a day -- but it's not something I deploy as a matter of course. And I don't expect it to survive more than a year before I have to just get rid of the guestbook. (Assuming the client keeps the site up at all, which is under review.) * So, is there a term for the web moral-equivalent of spammer? Those link-farm visitors who clutter up your site. blammers, perhaps? (blog-spammers). -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security code
On Thu, November 10, 2005 10:45 am, Gustavo Narea wrote: CAPTCHA tests are indispensables. The problem comes when you *only* use visual tests (such as visual turing numbers). If you need CAPTCHA tests, you may use them both visuals and audibles. This is a good example: https://www.e-gold.com/acct/login.html So the user who is both blind AND deaf? Or the blind user who is at a library computer with no audio output? I saw some research where out of four people with normal hearing, all four were unable to distinguish the crappy audio output into the correct word and use a site. Granted, a very small sample, and the audio from the test site may well have been at the low end of the spectrum for quality. But it was a real site, and these were just regular people roped in for a test of the audio's usefulness. As cool as CAPTCHA seems at first, I don't think it's going to be a long-term solution. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Richard Lynch wrote: AOL users WILL change their IP in a single [web-surfing] session. Ugh... I did not know that. That's horrible. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
On Thu, November 10, 2005 3:08 pm, GamblerZG wrote: Chris Shiflett wrote: GamblerZG wrote: I think it's still reasonable to restrict a session to a single IP. No, it's not, for all of the reasons Richard mentioned and more. I agree that using only IP to identify session is bad. Using only SID is ok. Using SIDs that are tied to a single IP is even _more secure_, since the possible attacker would need to have exactly the same IP as a victim of session hijacking. This comes at a price of a small inconvinience for dial-up users (since they would need to login on each reconnect), but I think such price it reasonable. Please pay attention. AOL *will* change the IP address of their users *IN* *THE* *MIDDLE* *OF* *A* *SESSION*. They will not be disconnected. They will not need to re-dial. Their phone line does not change its status from live to dead They will not be logged out of AOL. Their IP address *WILL* change, just because AOL felt like it [++]. You are rendering your site un-usable by all AOL users in a big way to rely on IP address not changing in mid-session. There is *NO* standard, law, rule, nor reason for an IP address to be assumed to be consistent, even in a single session/login/phone-call. ++ I suspect that AOL has a better reason internally for doing this than I felt like it but they don't NEED a better reason, and the effect is the same. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
GamblerZG wrote: This comes at a price of a small inconvinience for dial-up users (since they would need to login on each reconnect), but I think such price it reasonable. Ok, scrap this statement. I did not know about AOL thing. But this one still stands: IMO, the best way is to re-generate SIDs on each request, but such method will decrease perfomance of a script. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
GamblerZG wrote: I think it's still reasonable to restrict a session to a single IP. No, it's not, for all of the reasons Richard mentioned and more. I agree that using only IP to identify session is bad. Read more carefully. Enforcing IP consistency is bad, and many good reasons have already been given. Please quit making the same false statements without bothering to read the responses. We're trying to help you, and if you don't want to be helped, at least stop spreading misinformation. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Richard Lynch wrote: Please pay attention. Sorry, I did not see your message when I posted that. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
On Thu, November 10, 2005 3:29 pm, GamblerZG wrote: IMO, the best way is to re-generate SIDs on each request, but such method will decrease perfomance of a script. But if Cookies are off, you just destroyed their Back button in their browser, which should be a crime. Re-generate only when permission levels are crossed from normal user to admin -- or even just make them login again (or at least provide password) at that point. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
GamblerZG wrote: Richard Lynch wrote: Please pay attention. Sorry, I did not see your message when I posted that. Oh and would you mind using an email address that exists? Every time I reply to one of your posts, I get a returned mail from highstream.net saying your user doesn't exist... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: security code
Yep! It's called captcha. There is a PEAR package Text/CAPTCHA, and also you can find some other classes at phpclasses.org Good luck! Sincerely, Rosty Kerei [EMAIL PROTECTED] Clive [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi does any one have a class/function to generate those security code images. Yhe ones that you see on website that you must enter to submit a form thanks clive -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: security code
Hello, Clive. Depending on the target of your website, you shall need to keep in mind the (in)accessibility of this kind of tests: http://www.w3.org/TR/2003/WD-turingtest-20031105/ By the way, AFAIK they are also known as turing numbers. Regards. Clive wrote: Hi does any one have a class/function to generate those security code images. Yhe ones that you see on website that you must enter to submit a form thanks clive -- Best regards, Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Security Issues - Where to look?
*Distrust everything coming from your users, even their user agents* *If you make your scripts taking this into account, they'll be pretty secure* Actually, I believe that the one thing you can trust in, is their IP addresses. Isn't it? By the way, I liked the link that Pablo suggested: http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/ Cheers. Richard wrote: I've heard that php is not particularly secure, making it problematic if you intend to create a web site with commerce, etc. Is there a particular news group that addresses security issues? I'm looking for some guidlines on ensuring that my site is secure from malicious hackers. Thanks, Richard -- Best regards, Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Gustavo Narea wrote: By the way, I liked the link that Pablo suggested: http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/ Be careful. There is a lot of misinformation out there regarding PHP security, and this article is a good example. Here's something that caught my eye: The second solution is to only store their username and password in a cookie, and with every call to the script, validate the username and password and verify if the user is an administrator. If the problem is how to expose a user's sensitive data as much as possible, then this is a solution. However, I doubt that's the intent. This is such a common mistake that it is something I specifically search for when auditing a PHP application, as I mention in this talk: http://brainbulb.com/talks/php-security-audit-howto.pdf The PHP Security Consortium is trying to resolve this problem of misinformation in a positive way (we don't want to disparage people's hard work and spread bad vibes). We've created a library of links to approved resources that we've read through to make sure the advice given is sound. You can find this library here: http://phpsec.org/library/ Hope that helps. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Security Issues - Where to look?
if you really want to get into a conversation about security... it might be time to try to figure out how to create a security app/process which could be used to validate that an app is secure. the process could be a function of an automated app that looks/inspects code, as well as a manual process that inspects different portions of the app's logic/structure. there are a number of commercial code analyzers, although i don't know of any off the top of my head for php/web source based apps... might be time to seriously look at creating such an app/service.. there would probably be funding for this kind of app... ps.. this kind of app would not be trivial to create!!! -bruce -Original Message- From: Chris Shiflett [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 08, 2005 12:08 PM To: Gustavo Narea Cc: php-general@lists.php.net Subject: Re: [PHP] Re: Security Issues - Where to look? Gustavo Narea wrote: By the way, I liked the link that Pablo suggested: http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/ Be careful. There is a lot of misinformation out there regarding PHP security, and this article is a good example. Here's something that caught my eye: The second solution is to only store their username and password in a cookie, and with every call to the script, validate the username and password and verify if the user is an administrator. If the problem is how to expose a user's sensitive data as much as possible, then this is a solution. However, I doubt that's the intent. This is such a common mistake that it is something I specifically search for when auditing a PHP application, as I mention in this talk: http://brainbulb.com/talks/php-security-audit-howto.pdf The PHP Security Consortium is trying to resolve this problem of misinformation in a positive way (we don't want to disparage people's hard work and spread bad vibes). We've created a library of links to approved resources that we've read through to make sure the advice given is sound. You can find this library here: http://phpsec.org/library/ Hope that helps. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Hello, Chris. I will take into account what you said. It is right what you mentioned regarding that example. We have to take into account that cookies can be stolen. Thanks for the URLs, I will visit them. Cheers. Chris Shiflett wrote: Gustavo Narea wrote: By the way, I liked the link that Pablo suggested: http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/ Be careful. There is a lot of misinformation out there regarding PHP security, and this article is a good example. Here's something that caught my eye: The second solution is to only store their username and password in a cookie, and with every call to the script, validate the username and password and verify if the user is an administrator. If the problem is how to expose a user's sensitive data as much as possible, then this is a solution. However, I doubt that's the intent. This is such a common mistake that it is something I specifically search for when auditing a PHP application, as I mention in this talk: http://brainbulb.com/talks/php-security-audit-howto.pdf The PHP Security Consortium is trying to resolve this problem of misinformation in a positive way (we don't want to disparage people's hard work and spread bad vibes). We've created a library of links to approved resources that we've read through to make sure the advice given is sound. You can find this library here: http://phpsec.org/library/ Hope that helps. Chris -- Best regards, Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Security Issues - Where to look?
Hello. I found a document titled A Guide to Building Secure Web Applications http://www.cgisecurity.com/owasp/html/index.html while I was reading one of the documents you suggested us, and I would like to know what do you think about it? -- Best regards, Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Gustavo Narea wrote: I found a document titled A Guide to Building Secure Web Applications http://www.cgisecurity.com/owasp/html/index.html while I was reading one of the documents you suggested us, and I would like to know what do you think about it? The OWASP Guide is good, but that site has an old version. You can check OWASP for the latest: http://www.owasp.org/documentation/guide/guide_downloads.html Hope that helps. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
On Tue, November 8, 2005 9:43 am, Gustavo Narea wrote: *Distrust everything coming from your users, even their user agents* *If you make your scripts taking this into account, they'll be pretty secure* Actually, I believe that the one thing you can trust in, is their IP addresses. Isn't it? No! IP is useless for identification or authentication of the general web-surfer: Users behind firwalls will all appear to be from one (1) IP AOL users change IPs faster than drummers change underwear But even in the more restricted case of an IP you know will never change (e.g.: intranet application), that IP can be spoofed, by a knowlegable person. And/or traffic to/from that IP can be targetted and examined. The user's IP address is a useless bit of fluff you should ignore at all times if you REALLY care about security. This is not to say it's not TOTALLY useless... You might, for example, allow developers from 192.168.*.* to surf to your http://php.net/phpinfo page on a development box. After all, if somebody has already broken through enough walls to surf to it, and mask their IP as 192.168.*.*, you probably already have MUCH bigger problems than them seeing phpinfo() output... It would be BETTER to require a password of some kind, but it's not totally wack to just use $_SERVER['REMOTE_ADDR'] for this. You can use IP for statistical analysis of visits/visitors and be reasonably certain that MOST of the IP addresses are accurate and semi-static for a crude visitor/traffic monitoring, but knowing that a certain percentage of error is inherent to that data -- more like an opinion poll than anything. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
On Tue, November 8, 2005 2:55 pm, Gustavo Narea wrote: I found a document titled A Guide to Building Secure Web Applications http://www.cgisecurity.com/owasp/html/index.html while I was reading one of the documents you suggested us, and I would like to know what do you think about it? Seems like a winner to me. It's a bit back-dated in some regards, in terms of hot technologies, but the content is fundamentally sound, in general, and it has aged well. There's a lot of reading in there, and I was only able to spend an hour on it, skimming all the pages, and clicking on a few links. If it were updated, it would be VERY good. Just my non-expert opinion. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Thanks for the explanation, Richard. I'll definitely take it into account. So, let's distrust *everything*. Best regards. Richard Lynch wrote: On Tue, November 8, 2005 9:43 am, Gustavo Narea wrote: *Distrust everything coming from your users, even their user agents* *If you make your scripts taking this into account, they'll be pretty secure* Actually, I believe that the one thing you can trust in, is their IP addresses. Isn't it? No! IP is useless for identification or authentication of the general web-surfer: Users behind firwalls will all appear to be from one (1) IP AOL users change IPs faster than drummers change underwear But even in the more restricted case of an IP you know will never change (e.g.: intranet application), that IP can be spoofed, by a knowlegable person. And/or traffic to/from that IP can be targetted and examined. The user's IP address is a useless bit of fluff you should ignore at all times if you REALLY care about security. This is not to say it's not TOTALLY useless... You might, for example, allow developers from 192.168.*.* to surf to your http://php.net/phpinfo page on a development box. After all, if somebody has already broken through enough walls to surf to it, and mask their IP as 192.168.*.*, you probably already have MUCH bigger problems than them seeing phpinfo() output... It would be BETTER to require a password of some kind, but it's not totally wack to just use $_SERVER['REMOTE_ADDR'] for this. You can use IP for statistical analysis of visits/visitors and be reasonably certain that MOST of the IP addresses are accurate and semi-static for a crude visitor/traffic monitoring, but knowing that a certain percentage of error is inherent to that data -- more like an opinion poll than anything. -- Best regards, Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security Issues - Where to look?
Thanks once again, Chris. I must read that guide. Have a nice day! Chris Shiflett wrote: Gustavo Narea wrote: I found a document titled A Guide to Building Secure Web Applications http://www.cgisecurity.com/owasp/html/index.html while I was reading one of the documents you suggested us, and I would like to know what do you think about it? The OWASP Guide is good, but that site has an old version. You can check OWASP for the latest: http://www.owasp.org/documentation/guide/guide_downloads.html Hope that helps. Chris -- Best regards, Gustavo Narea. PHP Documentation - Spanish Translation Team. Valencia, Venezuela. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: security/sql issues with php
Bruce, If you're looking for commercial-grade open-source packages, I think you're going to have a pretty hard time finding much. Most commercial-grade software is...commercial. The truly robust open-source packages, i.e. Mozilla, MySQL, JBoss, BerkeleyDB, etc., are backed by some sort of commercial, or at the very least, corporate, entity. The rest, more often than not, are not commercial-grade; the support structures that companies require just don't exist for those packages. I've offered to help you before via our commercial framework, Lampshade, which handles I'd say 98% of everything you want, and can be easily customized or added to in order to handle the remaining 2%. It's not open-source, but it also doesn't need to be since the documentation is so extensive. It's used in applications for all sorts of organizations from Harvard University to companies traded on the NYSE. There may be other open frameworks that are used just as widely--I would venture to guess phpNuke and the-CMS-formerly-known-as-Mambo--but as you've discovered, they don't do half of the things you'd like to see all in one place. Also, Mambo's political machinations are a good example of what you don't want to see in a commercial-grade product. If you want to keep searching, I suppose no one's going to stop you. I'm just afraid it's not out there. Anyone, correct me if I'm wrong. Best of luck, Aaron Aaron Greenspan President CEO Think Computer Corporation http://www.thinkcomputer.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: security/sql issues with php
i would have thought (perhaps wrongly) that someone would have created a series of functions/routines and wrapped them in a package/lib to deal with the security issues that i've raised!! but i have to tell you. i've looked at some open source classess/apps that aren't that strong. in fact, some simply have no real checks on the data types/structure of the data being inserted into the db at all... and aaron, your app is a commercial app. for now, we're looking in the open source area where we can get to the underlying source. -bruce -Original Message- From: Aaron Greenspan [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 21, 2005 7:18 AM To: php-general@lists.php.net Subject: [PHP] Re: security/sql issues with php Bruce, If you're looking for commercial-grade open-source packages, I think you're going to have a pretty hard time finding much. Most commercial-grade software is...commercial. The truly robust open-source packages, i.e. Mozilla, MySQL, JBoss, BerkeleyDB, etc., are backed by some sort of commercial, or at the very least, corporate, entity. The rest, more often than not, are not commercial-grade; the support structures that companies require just don't exist for those packages. I've offered to help you before via our commercial framework, Lampshade, which handles I'd say 98% of everything you want, and can be easily customized or added to in order to handle the remaining 2%. It's not open-source, but it also doesn't need to be since the documentation is so extensive. It's used in applications for all sorts of organizations from Harvard University to companies traded on the NYSE. There may be other open frameworks that are used just as widely--I would venture to guess phpNuke and the-CMS-formerly-known-as-Mambo--but as you've discovered, they don't do half of the things you'd like to see all in one place. Also, Mambo's political machinations are a good example of what you don't want to see in a commercial-grade product. If you want to keep searching, I suppose no one's going to stop you. I'm just afraid it's not out there. Anyone, correct me if I'm wrong. Best of luck, Aaron Aaron Greenspan President CEO Think Computer Corporation http://www.thinkcomputer.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security/sql issues with php
have you tried googling on +application framework +php.. that seems like what you're looking for and several of these projects are commercial-grade and open source. i use dbasis as my application framework and highly recommend it -- its a component of the syntaxCMS project. i have also used blueshoes and mambo before on other sites here's an o'reilly article to get you started http://www.oreillynet.com/pub/wlg/6029 - schnippy On 9/21/05, bruce [EMAIL PROTECTED] wrote: i would have thought (perhaps wrongly) that someone would have created a series of functions/routines and wrapped them in a package/lib to deal with the security issues that i've raised!! but i have to tell you. i've looked at some open source classess/apps that aren't that strong. in fact, some simply have no real checks on the data types/structure of the data being inserted into the db at all... and aaron, your app is a commercial app. for now, we're looking in the open source area where we can get to the underlying source. -bruce -Original Message- From: Aaron Greenspan [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 21, 2005 7:18 AM To: php-general@lists.php.net Subject: [PHP] Re: security/sql issues with php Bruce, If you're looking for commercial-grade open-source packages, I think you're going to have a pretty hard time finding much. Most commercial-grade software is...commercial. The truly robust open-source packages, i.e. Mozilla, MySQL, JBoss, BerkeleyDB, etc., are backed by some sort of commercial, or at the very least, corporate, entity. The rest, more often than not, are not commercial-grade; the support structures that companies require just don't exist for those packages. I've offered to help you before via our commercial framework, Lampshade, which handles I'd say 98% of everything you want, and can be easily customized or added to in order to handle the remaining 2%. It's not open-source, but it also doesn't need to be since the documentation is so extensive. It's used in applications for all sorts of organizations from Harvard University to companies traded on the NYSE. There may be other open frameworks that are used just as widely--I would venture to guess phpNuke and the-CMS-formerly-known-as-Mambo--but as you've discovered, they don't do half of the things you'd like to see all in one place. Also, Mambo's political machinations are a good example of what you don't want to see in a commercial-grade product. If you want to keep searching, I suppose no one's going to stop you. I'm just afraid it's not out there. Anyone, correct me if I'm wrong. Best of luck, Aaron Aaron Greenspan President CEO Think Computer Corporation http://www.thinkcomputer.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: security while building online store
[EMAIL PROTECTED] wrote: kat Dzesi momak ;) I think you know PHP enough to make your code secure. Just take care (as Christian wrote)about sql-injections and register_globals. The biggest problem could be Linux/Apache/MySQL server security threat... --- avast! Antivirus: Outbound message clean. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security while building online store
You must read the articles by shiflet http://www.phpgurru.com/index.php?acion=pagingchid=www.shiflett.orgoffset=10 On 8/31/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: kat Dzesi momak ;) I think you know PHP enough to make your code secure. Just take care (as Christian wrote)about sql-injections and register_globals. The biggest problem could be Linux/Apache/MySQL server security threat... --- avast! Antivirus: Outbound message clean. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- *** phpgurru.com http://phpgurru.com [A php resource provider] *** \\\|/// \\ - - // ( @ @ ) PHP is too logical for my brain +---oOOo-(_)-oOOo--+ | Mian Shafiq ur Rehman | phpgurru.com http://phpgurru.com [A php resource provider] | 107 B, New Town, Multan Road | Lahore Pakistan | | Mobile: 0300 423 9385 | | ooo0 http://www.phpgurru.com | ( ) 0ooo E-Mail: [EMAIL PROTECTED] +---\ (( )--+ \_) ) / (_/
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 12, 2005, at 6:50 AM, Chris Shiflett wrote: As far as allowing [red] goes, you can just as easily add red to the list of available tags and not have to come up with a replacement for every other HTML tag that already exists. but what about the poor bastards that'll go around trying to use redin HTML/red? cs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Richard Davey wrote: I gave several valid good usability reasons, that I've yet to see anyone provide a coherent reason not to use. The usability arguments in favor of BBCode are fine. I'm not interested in that debate. I just don't want more people thinking that allowing BBCode somehow protects against XSS. As far as allowing [red] goes, you can just as easily add red to the list of available tags and not have to come up with a replacement for every other HTML tag that already exists. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Evert|Rooftop wrote: If you for example only allow iu and b doing this with bbcode would require extra cpu-cycles to convert [i] to i I don't really agree with this, because I think escaping the html + replacing bbcode would require less cpu cycles then scanning the string for invalid html and escaping them. Maybe someone has the time to benchmark this? Performance aside, that's a dangerous way of allowing a restricted set of HTML. You want to escape the entire string. The only difference is that you can convert some HTML entities back to their original form if you want to allow them to be interpreted. In other words, these approaches are almost identical, which is why BBCode has very little value. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP] Re: Security, Late Nights and Overall Paranoia
Hello Chris, Sunday, July 10, 2005, 2:31:57 AM, you wrote: CS I completely agree. I think you'll find that, when pressed, no one CS can really provide a good reason to use BBCode. I often see CS security cited as a reason, but it makes no sense. I gave several valid good usability reasons, that I've yet to see anyone provide a coherent reason not to use. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/11/05, Richard Davey [EMAIL PROTECTED] wrote: I gave several valid good usability reasons, that I've yet to see anyone provide a coherent reason not to use. Misuse of CPU cycles. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re[4]: [PHP] Re: Security, Late Nights and Overall Paranoia
Hello Greg, Monday, July 11, 2005, 3:46:24 PM, you wrote: GD On 7/11/05, Richard Davey [EMAIL PROTECTED] wrote: I gave several valid good usability reasons, that I've yet to see anyone provide a coherent reason not to use. GD Misuse of CPU cycles. So if you wanted to allow a user to say colour a piece of text red, they'd have to enter span style=color: redx/span to make it happen? Poor bastards (never mind the fact I'd love to see you use less CPU cycles to perfectly validate that tag than say [red][/red]). Interesting. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[4]: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/11/05, Richard Davey [EMAIL PROTECTED] wrote: u wanted to allow a user to say colour a piece of text red, they'd have to enter span style=color: redx/span to make it I wouldn't know, span isn't one of the tags I allow. happen? Poor bastards (never mind the fact I'd love to see you use less CPU cycles to perfectly validate that tag than say [red][/red]). I don't bother with perfect tag validation, and I doubt the phpbb bbcode people do either since they average about 2-3 exploits a month on Bugtraq. I allow a specific set of safe html tags and I provide a preview function. Even after that, if the user goofs up I allow a specific time span in which to edit the post to correct the goof. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re[6]: [PHP] Re: Security, Late Nights and Overall Paranoia
Hello Greg, Monday, July 11, 2005, 5:06:51 PM, you wrote: GD I wouldn't know, span isn't one of the tags I allow. If you stick to the plain vanilla HTML tags such as i, b, u, etc then BBCode is pointless - I agreed on this with you several posts ago. I don't however use it just for that, I use it to let thousands of kids add a little sparkle to their messages/profiles with colours, images, etc -- without them having to have good CSS/HTML knowledge (most of them could handle a font tag, but that'd break my XHTML Trans). This is the point I argued all along to which I get it's not really a security benefit (no, it's a user benefit) and it's a misuse of cpu cycles. For people I hold in such high regard, I'm ashamed at the lot of you :) GD I don't bother with perfect tag validation, and I doubt the phpbb GD bbcode people do either since they average about 2-3 exploits a GD month on Bugtraq. Not that I'd let an install of phpBB anywhere near a site I run, they didn't invent BBCode, and in all fairness to those guys the majority of their exploits are elsewhere. GD I allow a specific set of safe html tags and I provide a preview GD function. Even after that, if the user goofs up I allow a specific GD time span in which to edit the post to correct the goof. Ditto. I just don't force them to use HTML. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[6]: [PHP] Re: Security, Late Nights and Overall Paranoia
I've been loosely following this thread, and have a question now. Isn't one advantage of a bbcode type solution that you can more easily avoid session hijacking vis cross site scripting? If you allow html, then you open the door for people to add eventhandlers. I guess you could always strip them, but it seems like for simple stuff bbcode isn't a bad solution. On 7/11/05, Richard Davey [EMAIL PROTECTED] wrote: Hello Greg, Monday, July 11, 2005, 5:06:51 PM, you wrote: GD I wouldn't know, span isn't one of the tags I allow. If you stick to the plain vanilla HTML tags such as i, b, u, etc then BBCode is pointless - I agreed on this with you several posts ago. I don't however use it just for that, I use it to let thousands of kids add a little sparkle to their messages/profiles with colours, images, etc -- without them having to have good CSS/HTML knowledge (most of them could handle a font tag, but that'd break my XHTML Trans). This is the point I argued all along to which I get it's not really a security benefit (no, it's a user benefit) and it's a misuse of cpu cycles. For people I hold in such high regard, I'm ashamed at the lot of you :) GD I don't bother with perfect tag validation, and I doubt the phpbb GD bbcode people do either since they average about 2-3 exploits a GD month on Bugtraq. Not that I'd let an install of phpBB anywhere near a site I run, they didn't invent BBCode, and in all fairness to those guys the majority of their exploits are elsewhere. GD I allow a specific set of safe html tags and I provide a preview GD function. Even after that, if the user goofs up I allow a specific GD time span in which to edit the post to correct the goof. Ditto. I just don't force them to use HTML. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
The point is.. If you for example only allow iu and b doing this with bbcode would require extra cpu-cycles to convert [i] to i I don't really agree with this, because I think escaping the html + replacing bbcode would require less cpu cycles then scanning the string for invalid html and escaping them. Maybe someone has the time to benchmark this? Whatever the outcome will be, I would still prefer i over [i] because I'm a standards guy =) regards, Evert Jonathan Kart wrote: I've been loosely following this thread, and have a question now. Isn't one advantage of a bbcode type solution that you can more easily avoid session hijacking vis cross site scripting? If you allow html, then you open the door for people to add eventhandlers. I guess you could always strip them, but it seems like for simple stuff bbcode isn't a bad solution. On 7/11/05, Richard Davey [EMAIL PROTECTED] wrote: Hello Greg, Monday, July 11, 2005, 5:06:51 PM, you wrote: GD I wouldn't know, span isn't one of the tags I allow. If you stick to the plain vanilla HTML tags such as i, b, u, etc then BBCode is pointless - I agreed on this with you several posts ago. I don't however use it just for that, I use it to let thousands of kids add a little sparkle to their messages/profiles with colours, images, etc -- without them having to have good CSS/HTML knowledge (most of them could handle a font tag, but that'd break my XHTML Trans). This is the point I argued all along to which I get it's not really a security benefit (no, it's a user benefit) and it's a misuse of cpu cycles. For people I hold in such high regard, I'm ashamed at the lot of you :) GD I don't bother with perfect tag validation, and I doubt the phpbb GD bbcode people do either since they average about 2-3 exploits a GD month on Bugtraq. Not that I'd let an install of phpBB anywhere near a site I run, they didn't invent BBCode, and in all fairness to those guys the majority of their exploits are elsewhere. GD I allow a specific set of safe html tags and I provide a preview GD function. Even after that, if the user goofs up I allow a specific GD time span in which to edit the post to correct the goof. Ditto. I just don't force them to use HTML. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Fri, July 8, 2005 11:25 am, Ezra Nugroho said: Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. We may not stop the information redirection. We can make the information invalid. NO!!! IP is *USELESS* as identification! AOL users change IP more often than drummers change their underwear. EVERY user working at IBM is gonna have the *same* IP address. You will only break your site for legitimate users, and not make anything useful to stop Bad Guys. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP] Re: Security, Late Nights and Overall Paranoia
Hello Greg, Friday, July 8, 2005, 5:00:23 PM, you wrote: GD On 7/8/05, Ryan A [EMAIL PROTECTED] wrote: Yep, but this has no way of breaking my html GD If [/i] is missing, it'd be the same as /i being missing. I have to say I disagree, because with all modern BBcode parsers it would never get to that stage. If the user misses out the closing [/i] tag then when it comes to parse the BBcode into HTML it'd never happen. All decent BBcode parsers search for both pairs of tag. If an opening [i] is found but no corresponding close tag, both would be ignored and skip onto the next check. I haven't seen one that did a straight str_replace for a long time now (although I guess they still exist! and in those cases I agree with you, they are pointless and utterly insecure). If you allow direct HTML as user input, you HAVE to check and validate every single aspect of their HTML for all possible errors, typos, included XSS attacks, etc - and if you fail in even one of these checks, they can break the layout of your site, or worse. Whereas with BBcode the worst that can happen (in this instance) is that the user looks like an idiot because [i] tags are left in their input. Another benefit IMHO is that you control what [i] gets turned into, for example I don't use i tags in my HTML as I don't believe they are semantically descriptive. But not everyone will know what the heck an em does, just as with [b] to strong, etc. The second you allow for direct use you do open, imho, a whole can of worms that you'd better be absolutely sure you have faultlessly checked and double-checked, because as you know there's no room for error these days. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/9/05, Richard Davey [EMAIL PROTECTED] wrote: I have to say I disagree, because with all modern BBcode parsers it would never get to that stage. The same regular expression magic that keeps you from forgetting your [/i] can just as easily keep you from forgetting your /i. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re[4]: [PHP] Re: Security, Late Nights and Overall Paranoia
Hello Greg, Saturday, July 9, 2005, 6:40:06 PM, you wrote: GD The same regular expression magic that keeps you from forgetting your GD [/i] can just as easily keep you from forgetting your /i. The difference is the extra hoops your reg exps will have to jump through, and have to jump through perfectly. You will have to disallow all 's and 's, but do allow them for i, b, etc etc. Then check there has been nothing malicious inserted inside every one of those tags in any shape or form, and all combinations thereof. I'm sorry but I fail to see how *having* to perform masses of flawless reg-ex kung-fu is a good thing, in my mind it just widens the margin for developer error, which is a never a plus point. It's horses for courses though, in the CMS I built for myself I allow any damn thing I want ;) In the forum built for thousands of teenagers, you'd have to be out of your mind to allow it. May as well just give them your server reboot button while you're at it and ask not to touch. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re[5]: [PHP] Re: Security, Late Nights and Overall Paranoia
To follow-up my own post... which is sad I know, but hey... Saturday, July 9, 2005, 7:08:37 PM, I wrote: RD The difference is the extra hoops your reg exps will have to jump RD through, and have to jump through perfectly. You will have to disallow RD all 's and 's, but do allow them for i, b, etc etc. Then check I forgot to add that BB style codes come into real use for things a little more advanced than i. For example [red] to colour some text. If you wish to allow this in HTML format you can either invalidate your XHTML and allow font tags, otherwise allow spans with embedded CSS?! Even if you do allow font you're then parsing for color= and nothing else, with potential variable width colours. After a short while you'll find yourself having to write an HTML validator tool (and I'm sorry but I have *never* seen one that worked flawlessly yet). Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Greg Donald wrote: [i]This text will be in italics.[/i] [b]This text will be in bold.[/b] [url=http://php.net]This will be a URL that points to php.net.[/url] While I do not disagree with the information content of your post, I do think this sort of thing is pretty silly. If you're gonna allow the i tag then just allow it. There's no point in allowing something else just to spend CPU cycles converting it to what you could have allowed in the first place. I completely agree. I think you'll find that, when pressed, no one can really provide a good reason to use BBCode. I often see security cited as a reason, but it makes no sense. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Ezra Nugroho wrote: Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. If by HAVE to you mean MUST NEVER, then I agree. :-) Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security question...??
Matthew Weier O'Phinney wrote: The reason I ask is that (1) it shouldn't matter HOW the HTTP request is initiated. What *should* matter is that the page handles the request gracefully and returns something (HTTP headers only, or headers + page) as a result. That's an interesting way of explaining that. I think I might try to come up with something similar, since this question comes up a lot. It seems clearer than any way that I've explained it in the past. Prior, when people asked me how to prevent spoofing forms, I would usually say something to the effect of, don't worry about it, and throw in CSRF attacks as the only caveat. My point was that it shouldn't matter what the client sends, as long as it abides by your rules. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Security, Late Nights and Overall Paranoia
The typical way that forums handle this is to use what is called BBCode. In short, you have a non-HTML way for users to supply information that will produce markup instead of just plain text. So if you want to allow italics, bolds, URL's, etc. then you have some codes for it like: [i]This text will be in italics.[/i] [b]This text will be in bold.[/b] [url=http://php.net]This will be a URL that points to php.net.[/url] Mailing archives probably have some code that does this... or you could see what the maintainers of phpBB do under the hood. Ah, the beauty of Open Source! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/8/05, Jason Barnett [EMAIL PROTECTED] wrote: The typical way that forums handle this is to use what is called BBCode. In short, you have a non-HTML way for users to supply information that will produce markup instead of just plain text. So if you want to allow italics, bolds, URL's, etc. then you have some codes for it like: [i]This text will be in italics.[/i] [b]This text will be in bold.[/b] [url=http://php.net]This will be a URL that points to php.net.[/url] While I do not disagree with the information content of your post, I do think this sort of thing is pretty silly. If you're gonna allow the i tag then just allow it. There's no point in allowing something else just to spend CPU cycles converting it to what you could have allowed in the first place. It doesn't make it more safe that way. Just clean out the stuff you don't want and be done with it. define( 'ALLOWED_TAGS', 'abblockquotebrcitedddivdldtecodeemiliolpstrongttul' ); $string = strip_tags( $string, ALLOWED_TAGS ); Cleaning an a tag can be accomplished just as easily as cleaning a [url] tag. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Hey, clip The typical way that forums handle this is to use what is called BBCode. In short, you have a non-HTML way for users to supply [i]This text will be in italics.[/i] [b]This text will be in bold.[/b] /clip If you're gonna allow the i tag then just allow it. There's no point in allowing something else just to spend CPU cycles converting it to what you could have allowed in the first place. It doesn't make it more safe that way. Just clean out the stuff you don't want and be done with it. define( 'ALLOWED_TAGS', 'abblockquotebrcitedddivdldtecodeemiliolpstro ngttul' ); $string = strip_tags( $string, ALLOWED_TAGS ); The problem with this approach is if people dont close their tags properly (mistake or purpose) they can screw up your page eg br blah blah blah blah citesomethingcite (no closing tag) my $0.2 Cheers, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/8/05, Ryan A [EMAIL PROTECTED] wrote: The problem with this approach is if people dont close their tags properly Nothing makes it impossible for me to hand type and not close one of those tags. [i]blah -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Hey, The problem with this approach is if people dont close their tags properly Nothing makes it impossible for me to hand type and not close one of those tags. [i]blah Yep, but this has no way of breaking my html the max you would get is: [i this will be in italics which is obvious that the person who wrote the above forgot to write the tag properly. but if you have something like this: !-- start page code --! table tr td !-- end page code --! í blah blah blah blah blah blah blah blah blah blah blah blah !-- start page code --! /td tr /table !-- end page code --! Not a very good example, but you should get the idea.. Cheers, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/8/05, Ryan A [EMAIL PROTECTED] wrote: Yep, but this has no way of breaking my html If [/i] is missing, it'd be the same as /i being missing. I can just as easily clean out any missing /i tags as I can any missing [/i] tags. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Yep, but this has no way of breaking my html If [/i] is missing, it'd be the same as /i being missing. I can just as easily clean out any missing /i tags as I can any missing [/i] tags. I am not really bothered about the closing tags (for example /i) I am more bothered about the opening closing tag (for example i when it should be i) as this can mess up my page...but this cant do squat: [i or this: i] Cheers, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 8, 2005, at 4:21 AM, [EMAIL PROTECTED] wrote: Personally, I don't think it's a bad idea at all. The best way (and probably ONLY real way) to achieve decent security would be to limit the subset of tags the user can post. Best way to achieve this is to use your own tagging system (e.g. [p] instead of p) this will allow you to strip_tags to protect against injections and limit the tags the author can post (to protect against injection-through-conversion attacks). Use a pcre replace to replace all occurances of the allowed tags with the HTML equivilents upon page rendering (it's usually best to sore your tag format in the database instead of the raw HTML). As for SSL, is it really needed? The data would, in most cases, not be considered highly important. It would just leverage another server requirement on the end-user. If you're writing something for public consumption, it needs to be as flexible as possible. Besides, SSL has very little to do with PHP and is therefore not really worth thinking about. In order to include support for running the Administration of the CMS through SSL, simply allow the Admin pages to run on a different host. Last word, IP and User Agent tracking are more useless than MAC filtering on firewalls. In the long run, it'll simply add more overhead to your application and produce no useful information (unless you're using it purely for statistics).# PS: This is going through web-mail, so there's a good chance it might not reach the list. Unless I'm really missing something important, for 'this' particular part of the application, any BBCode/Tag stripping/rewriting scheme would be useless since what they will be editing is the actual templates that make the page, therefore all tags would have to be allowed. It's not the legitimate user I'm worried about doing something wrong, it's that if it's possible for a legitimate user to do this, then some Bad Guy somewhere may be able to do this too. I've pretty much eliminated the possibility of someone using say cURL or some other mechanism to post information to the form processor directly. If they can guess two md5 hashes of two different random numbers that may or may not be set to allow the transaction as well as the ip/user agent associated with one of the numbers, then nothing I do will keep them out because they are GOD, or have a _lot_ of time on their hands. Plus, the clients account will have more than likely been shut down for going over their bandwidth quota from the attempts. [If I'm wrong in my assumptions here, someone please slap me in the head] What I'm worried about is someone grabbing a valid cookie id, and in the short time-span that it _is_ valid, being able to pull up the actual post form, which will then give them the second number and the ip/user agent, and legitimately posting malicious code. So yes, SSL is necessary at this point to try to keep that cookie secret. If it can, which is what I'm being paranoid about. This is a weak spot in the code because I have to trust that the user is who they say they are, all things considered. And at this point, I'm relying on SSL to be the security rock that plugs up this hole. Is SSL enough to keep the cookie safe? Is it absolutely stupid to allow this, even if there will only ever be one username/password combo that will be allowed to access this part? Other parts of the admin console will be open to other users though. The actual web site, ie the pages created and maintained by the application, is open to the public and there is no SSL there, no cookies or info other than the html request/response of a 'normal' site. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On 7/8/05, Ryan A [EMAIL PROTECTED] wrote: I am not really bothered about the closing tags (for example /i) I am more bothered about the opening closing tag (for example i when it should be i) as this can mess up my page...but this cant do squat: [i or this: i] That's where a good preview function comes in handy. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. There are a gazillion of sites (CMS-based, wiki-based, etc, including php.net) that allow users to contribute html. They are not concern about security of data delivery. I think, page breaking html is more prominent issue, which you could eliminate with BBcode or wiki language. Perhaps you are being a little paranoid? Or do I miss something? Unless I'm really missing something important, for 'this' particular part of the application, any BBCode/Tag stripping/rewriting scheme would be useless since what they will be editing is the actual templates that make the page, therefore all tags would have to be allowed. It's not the legitimate user I'm worried about doing something wrong, it's that if it's possible for a legitimate user to do this, then some Bad Guy somewhere may be able to do this too. I've pretty much eliminated the possibility of someone using say cURL or some other mechanism to post information to the form processor directly. If they can guess two md5 hashes of two different random numbers that may or may not be set to allow the transaction as well as the ip/user agent associated with one of the numbers, then nothing I do will keep them out because they are GOD, or have a _lot_ of time on their hands. Plus, the clients account will have more than likely been shut down for going over their bandwidth quota from the attempts. [If I'm wrong in my assumptions here, someone please slap me in the head] What I'm worried about is someone grabbing a valid cookie id, and in the short time-span that it _is_ valid, being able to pull up the actual post form, which will then give them the second number and the ip/user agent, and legitimately posting malicious code. So yes, SSL is necessary at this point to try to keep that cookie secret. If it can, which is what I'm being paranoid about. This is a weak spot in the code because I have to trust that the user is who they say they are, all things considered. And at this point, I'm relying on SSL to be the security rock that plugs up this hole. Is SSL enough to keep the cookie safe? Is it absolutely stupid to allow this, even if there will only ever be one username/password combo that will be allowed to access this part? Other parts of the admin console will be open to other users though. The actual web site, ie the pages created and maintained by the application, is open to the public and there is no SSL there, no cookies or info other than the html request/response of a 'normal' site. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. That's what XSS is all about. I don't have the link handy but I do have a PDF file that I found a while back that explains how this happens, and to tell the truth, it scared the s*** outa me. To the point that I really don't trust any online commerce, although I do still use it, just as I still give the waitress/waiter my credit card at a restaurant, even though I know that's where most of the identity theft/stolen CC numbers comes from. There are a gazillion of sites (CMS-based, wiki-based, etc, including php.net) that allow users to contribute html. They are not concern about security of data delivery. Yeah I know... :P I think, page breaking html is more prominent issue, which you could eliminate with BBcode or wiki language. Perhaps you are being a little paranoid? Or do I miss something? So yeah, I'm being paranoid but I'm also trying to cover as many bases as I can and yet still provide some decent functionality. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 8, 2005, at 12:31 PM, Edward Vermillion wrote: On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. That's what XSS is all about. I don't have the link handy but I do have a PDF file that I found a while back that explains how this happens, and to tell the truth, it scared the s*** outa me. To the point that I really don't trust any online commerce, although I do still use it, just as I still give the waitress/waiter my credit card at a restaurant, even though I know that's where most of the identity theft/stolen CC numbers comes from. Here's one of the links http://www.acros.si/papers/session_fixation.pdf Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. We may not stop the information redirection. We can make the information invalid. Regards, Ezra On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote: On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. That's what XSS is all about. I don't have the link handy but I do have a PDF file that I found a while back that explains how this happens, and to tell the truth, it scared the s*** outa me. To the point that I really don't trust any online commerce, although I do still use it, just as I still give the waitress/waiter my credit card at a restaurant, even though I know that's where most of the identity theft/stolen CC numbers comes from. There are a gazillion of sites (CMS-based, wiki-based, etc, including php.net) that allow users to contribute html. They are not concern about security of data delivery. Yeah I know... :P I think, page breaking html is more prominent issue, which you could eliminate with BBcode or wiki language. Perhaps you are being a little paranoid? Or do I miss something? So yeah, I'm being paranoid but I'm also trying to cover as many bases as I can and yet still provide some decent functionality. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
On Jul 8, 2005, at 1:25 PM, Ezra Nugroho wrote: Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. We may not stop the information redirection. We can make the information invalid. Well, yes and no. If the bad guy can get the cookie, it's also likely that he's got all the information the valid user is sending you too, such as ip, user agent, whatever... So he's probably going to send all that along with the stolen cookie, and the checks you have will let him in. All the ip, user agent, etc. checks do is slow down a brute-force attack. They have to guess more than one correct value to get in. But that cookie that's the prize. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Security, Late Nights and Overall Paranoia
True. People can steal sessions within a firewall as well. Unless if browsers can do digital signature, there is no a good way to validate users. I think you would agree that for now it comes down to two choices: 1. Focus on convenience, let security slack a little or 2. Focus on security, and tolerate some inconvenience. W3C, please do something!! On Fri, 2005-07-08 at 14:53 -0400, Michael Caplan wrote: I just was reading a thread on the PHPSEC list, where one of the developers of FUD Forums was (Ilia) was mentioning his experience with AOL users. He claims that IPs can change as frequently as every request to the server. I've also noted similar (but not as drastic) effects. IPs are really not a good fingerprint for a user, unless you are fine with invalidating users on a frequent basis Michael -Original Message- From: Ezra Nugroho [mailto:[EMAIL PROTECTED] Sent: Friday, July 08, 2005 11:49 AM To: Michael Caplan Subject: RE: [PHP] Re: Security, Late Nights and Overall Paranoia True, but it's better than nothing. IP doesn't change that often, maybe at worst once every hour. Sensitive cookies should not live that long anyway. It's not a great solution, but it's something. On Fri, 2005-07-08 at 14:41 -0400, Michael Caplan wrote: IPs are unreliable. An ip will change frequently if a user travels through a proxy pool, like AOL users, or just about any user from a large ISP. Michael -Original Message- From: Ezra Nugroho [mailto:[EMAIL PROTECTED] Sent: Friday, July 08, 2005 11:25 AM To: Edward Vermillion Cc: php Lists Subject: Re: [PHP] Re: Security, Late Nights and Overall Paranoia Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. We may not stop the information redirection. We can make the information invalid. Regards, Ezra On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote: On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. That's what XSS is all about. I don't have the link handy but I do have a PDF file that I found a while back that explains how this happens, and to tell the truth, it scared the s*** outa me. To the point that I really don't trust any online commerce, although I do still use it, just as I still give the waitress/waiter my credit card at a restaurant, even though I know that's where most of the identity theft/stolen CC numbers comes from. There are a gazillion of sites (CMS-based, wiki-based, etc, including php.net) that allow users to contribute html. They are not concern about security of data delivery. Yeah I know... :P I think, page breaking html is more prominent issue, which you could eliminate with BBcode or wiki language. Perhaps you are being a little paranoid? Or do I miss something? So yeah, I'm being paranoid but I'm also trying to cover as many bases as I can and yet still provide some decent functionality. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php CONFIDENTIALITY NOTICE This message contains confidential information intended only for the use of the individual or entity named as recipient. Any dissemination, distribution or copying of this communication by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify us and delete your copy. Thank you. AVIS DE CONFIDENTIALITÉ Les informations contenues aux présentes sont de nature privilégiée et confidentielle. Elles ne peuvent être utilisées que par la personne ou l'entité dont le nom paraît comme destinataire. Si le lecteur du présent message n'est pas le destinataire prévu, il est par les présentes prié de noter qu'il est strictement interdit de divulguer, de distribuer ou de copier ce message. Si ce message vous a été transmis par mégarde, veuillez nous en aviser immédiatement et supprimer votre copie. Merci. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Security, Late Nights and Overall Paranoia
Okay: From what I´ve read here, there seems to be a lot of useful information - very litte of which is relevent to the question. My understanding is that you(the OP) have a template-editing page, which your designers can log into in order to edit the page, without having ftp/sftp access? It is reasonably possible to secure this, and you seem to have the gist of what is necessary. In fact you seem a little paranoid(That´s a good thing). For a list of what to check and what not to check, one good place to start would be to go through a PHP info page, pick out what is useful(for verification) and leave behind what isn´t. One possible step to secure against brute-force is to use captchas. What you will have to ultimately accept, is that no matter how much you secure a computer, it will never be completely secure - no matter what. On 7/8/05, Ezra Nugroho [EMAIL PROTECTED] wrote: True. People can steal sessions within a firewall as well. Unless if browsers can do digital signature, there is no a good way to validate users. I think you would agree that for now it comes down to two choices: 1. Focus on convenience, let security slack a little or 2. Focus on security, and tolerate some inconvenience. W3C, please do something!! On Fri, 2005-07-08 at 14:53 -0400, Michael Caplan wrote: I just was reading a thread on the PHPSEC list, where one of the developers of FUD Forums was (Ilia) was mentioning his experience with AOL users. He claims that IPs can change as frequently as every request to the server. I've also noted similar (but not as drastic) effects. IPs are really not a good fingerprint for a user, unless you are fine with invalidating users on a frequent basis Michael -Original Message- From: Ezra Nugroho [mailto:[EMAIL PROTECTED] Sent: Friday, July 08, 2005 11:49 AM To: Michael Caplan Subject: RE: [PHP] Re: Security, Late Nights and Overall Paranoia True, but it's better than nothing. IP doesn't change that often, maybe at worst once every hour. Sensitive cookies should not live that long anyway. It's not a great solution, but it's something. On Fri, 2005-07-08 at 14:41 -0400, Michael Caplan wrote: IPs are unreliable. An ip will change frequently if a user travels through a proxy pool, like AOL users, or just about any user from a large ISP. Michael -Original Message- From: Ezra Nugroho [mailto:[EMAIL PROTECTED] Sent: Friday, July 08, 2005 11:25 AM To: Edward Vermillion Cc: php Lists Subject: Re: [PHP] Re: Security, Late Nights and Overall Paranoia Here is one security measure that you HAVE to do if you allow people to submit contents to your site. 1. track client's IP. 2. Associate sensitive cookies with the IP, if they don't match, ignore it or invalidate the cookie. We may not stop the information redirection. We can make the information invalid. Regards, Ezra On Fri, 2005-07-08 at 12:31 -0500, Edward Vermillion wrote: On Jul 8, 2005, at 12:02 PM, Ezra Nugroho wrote: I am just wondering, how could someone craft an html to steal cookies? If your cookie distribution is done right, I don't think you need to worry about this. That's what XSS is all about. I don't have the link handy but I do have a PDF file that I found a while back that explains how this happens, and to tell the truth, it scared the s*** outa me. To the point that I really don't trust any online commerce, although I do still use it, just as I still give the waitress/waiter my credit card at a restaurant, even though I know that's where most of the identity theft/stolen CC numbers comes from. There are a gazillion of sites (CMS-based, wiki-based, etc, including php.net) that allow users to contribute html. They are not concern about security of data delivery. Yeah I know... :P I think, page breaking html is more prominent issue, which you could eliminate with BBcode or wiki language. Perhaps you are being a little paranoid? Or do I miss something? So yeah, I'm being paranoid but I'm also trying to cover as many bases as I can and yet still provide some decent functionality. Edward Vermillion [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php CONFIDENTIALITY NOTICE This message contains confidential information intended only for the use of the individual or entity named as recipient. Any dissemination, distribution or copying of this communication by anyone other
RE: [PHP] Re: security question...??
rene... the scenario that i'm envisioning could very well cause people to get ticked. but i also can easily see financial institutions starting to tell their customers, that unless your system is of a certain level, or running a certain kind of browser, that you'll get charged more to do business with them... security is an issue, and it's going to get larger. and that will require thinking about the user/client's setup.. if i as a bank, refuse to allow you to signin to my server, because i detect that your client is not valid/legitimate, meaning i think it's been hacked, how have i trampled the rights of anyone. i haven't. will some customers run, sure.. perhaps.. will i potentially feel better. yeah. will i potentially have something that i can promote as an extra level of security that others don't have, maybe.. let people continue to read/hear about massive losses of data and see what happens... rene, you also have to understand, i'm not trying to determine if the user's entire system is 'clean/valid'. i'd settle for a way of knowing that the browser/client that i'm talking to is legitimate!! -bruce -Original Message- From: Rene Brehmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 21, 2005 3:18 PM To: php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? Documented research indicate that on Tue, 21 Jun 2005 13:37:50 -0700, bruce wrote: chris... what you state is true at the extreme... but in the case of an client app, i could already extract information about the various apps that make up the client.. ie if, as in the case of IE, I was able to get information from the IE browser about various dlls that make up the browser. if these pieces of information correclt match what msoft would state should be there, then i could assume that the app was/is legitimate. BUT: That would mean that you can't take into account any plugins or extensions the user might install. And the security leak you're afraid of might not even be IN the browser program used. It might as well be a packet sniffer on the outside of the user's firewall ... and here's why. while you may not give a damm, there will be a growing chorus of people who'll want to know that the developers/sites are doing everything they can to ensure the safety of the entire transaction. in fact, i'm willing to bet that somehting like what i've been discussing will be delivered, and promoted as a security/selling point... I think it's more a matter of education and morale than anything else. You can't take responsibility for all clients not screwing up their own system. You just have to hope and trust, that when you tell your users to use this and that browser, and take this and that precaution, that they actually do it, and not install a whole bunch of crap that creates a security problem. What you're asking for is basically a way to control what users do on their own computers, and refuse them if you don't like what they've done. It's not very short of invasion of privacy. Electronic Arts already do that with their games (spy on your computer without your permission, and the refuse you to play the game you legally paid for, because you have other legally paid programs that they don't approve of). What you can do however, is to develop an app that can run a security test locally on the user's computer, and have that app sign off on the user being safe enough for you to want to deal with him. And then force them to regularly have to do that again. But I'm telling you, the more troublesome you make it for your users to use your stuff, the more users you'll loose, and fast. Mostly thanks to MS and Apple, computer users today know very little about their computers, or how they work, or how they protect themselves, and we teach them that they should all and anything that comes their way. So it's continuingly limited what you can actually ask a computer user to put up with, they'll just go somewhere else that's less hazzlesome (that's the whole reason the majority use IE: It's there, it's easy to use, it gets the job done, and it doesn't complain a whole lot). The majority of end-users don't care, or know, or understand, simple security precautions when it comes to network traffic. Education and discipline is, in the end, the only means to achieve what you want. /rambling off -- Rene Brehmer aka Metalbunny We have nothing to fear from free speech and free information on the Internet, but pop-up advertising! http://metalbunny.net/ My little mess of things... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security question...??
Okay Bruce: There's one very major problem with your suggestion - IT CAN NOT BE DONE. YOU CAN NOT TEST A REMOTE PIECE OF SOFTWARE TO MAKE SURE THAT THERE HAVE BEEN NO CHANGES TO IT. There are ways of checking what type of valid browser, or what type of valid Operating System, your using, but invalid or illegitimate, would return the same test results as valid or legitimate, since anybody hacking them would hack them to return the valid/legitimate results to such tests. Just incase you didn't understand me earlier - YOU CAN NOT RELIABLY TEST REMOTE SOFTWARE TO MAKE SURE THAT IT HAS NOT BEEN HACKED AND/OR CRACKED On 6/22/05, bruce [EMAIL PROTECTED] wrote: rene... the scenario that i'm envisioning could very well cause people to get ticked. but i also can easily see financial institutions starting to tell their customers, that unless your system is of a certain level, or running a certain kind of browser, that you'll get charged more to do business with them... security is an issue, and it's going to get larger. and that will require thinking about the user/client's setup.. if i as a bank, refuse to allow you to signin to my server, because i detect that your client is not valid/legitimate, meaning i think it's been hacked, how have i trampled the rights of anyone. i haven't. will some customers run, sure.. perhaps.. will i potentially feel better. yeah. will i potentially have something that i can promote as an extra level of security that others don't have, maybe.. let people continue to read/hear about massive losses of data and see what happens... rene, you also have to understand, i'm not trying to determine if the user's entire system is 'clean/valid'. i'd settle for a way of knowing that the browser/client that i'm talking to is legitimate!! -bruce -Original Message- From: Rene Brehmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 21, 2005 3:18 PM To: php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? Documented research indicate that on Tue, 21 Jun 2005 13:37:50 -0700, bruce wrote: chris... what you state is true at the extreme... but in the case of an client app, i could already extract information about the various apps that make up the client.. ie if, as in the case of IE, I was able to get information from the IE browser about various dlls that make up the browser. if these pieces of information correclt match what msoft would state should be there, then i could assume that the app was/is legitimate. BUT: That would mean that you can't take into account any plugins or extensions the user might install. And the security leak you're afraid of might not even be IN the browser program used. It might as well be a packet sniffer on the outside of the user's firewall ... and here's why. while you may not give a damm, there will be a growing chorus of people who'll want to know that the developers/sites are doing everything they can to ensure the safety of the entire transaction. in fact, i'm willing to bet that somehting like what i've been discussing will be delivered, and promoted as a security/selling point... I think it's more a matter of education and morale than anything else. You can't take responsibility for all clients not screwing up their own system. You just have to hope and trust, that when you tell your users to use this and that browser, and take this and that precaution, that they actually do it, and not install a whole bunch of crap that creates a security problem. What you're asking for is basically a way to control what users do on their own computers, and refuse them if you don't like what they've done. It's not very short of invasion of privacy. Electronic Arts already do that with their games (spy on your computer without your permission, and the refuse you to play the game you legally paid for, because you have other legally paid programs that they don't approve of). What you can do however, is to develop an app that can run a security test locally on the user's computer, and have that app sign off on the user being safe enough for you to want to deal with him. And then force them to regularly have to do that again. But I'm telling you, the more troublesome you make it for your users to use your stuff, the more users you'll loose, and fast. Mostly thanks to MS and Apple, computer users today know very little about their computers, or how they work, or how they protect themselves, and we teach them that they should all and anything that comes their way. So it's continuingly limited what you can actually ask a computer user to put up with, they'll just go somewhere else that's less hazzlesome (that's the whole reason the majority use IE: It's there, it's easy to use, it gets the job done, and it doesn't complain a whole lot). The majority of end-users don't care, or know, or understand, simple security precautions when it comes
RE: [PHP] Re: security question...??
sure it can rory... i can give you a file... i create a hash of the file... if i have a process within the file that i give you that allows the file to more or less create the hash of itself, and if i can query/access the file to get the information, then i can more or less determine if the file has been changed.. would this approach require additional functionality.. sure but it might also require no more than a plugin... the issue is that there are multiple ways of tryng to determine if you have a legitimate file/app... i hope you don't have this narrow focus with any of your customers, or in your daily job.. or you might simply need to recognize that there's a lot more that you don't know, than you do... ahh to be young! do some research, check some of the literature.. -bruce -Original Message- From: Rory Browne [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 6:58 AM To: [EMAIL PROTECTED] Cc: Rene Brehmer; php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? Okay Bruce: There's one very major problem with your suggestion - IT CAN NOT BE DONE. YOU CAN NOT TEST A REMOTE PIECE OF SOFTWARE TO MAKE SURE THAT THERE HAVE BEEN NO CHANGES TO IT. There are ways of checking what type of valid browser, or what type of valid Operating System, your using, but invalid or illegitimate, would return the same test results as valid or legitimate, since anybody hacking them would hack them to return the valid/legitimate results to such tests. Just incase you didn't understand me earlier - YOU CAN NOT RELIABLY TEST REMOTE SOFTWARE TO MAKE SURE THAT IT HAS NOT BEEN HACKED AND/OR CRACKED On 6/22/05, bruce [EMAIL PROTECTED] wrote: rene... the scenario that i'm envisioning could very well cause people to get ticked. but i also can easily see financial institutions starting to tell their customers, that unless your system is of a certain level, or running a certain kind of browser, that you'll get charged more to do business with them... security is an issue, and it's going to get larger. and that will require thinking about the user/client's setup.. if i as a bank, refuse to allow you to signin to my server, because i detect that your client is not valid/legitimate, meaning i think it's been hacked, how have i trampled the rights of anyone. i haven't. will some customers run, sure.. perhaps.. will i potentially feel better. yeah. will i potentially have something that i can promote as an extra level of security that others don't have, maybe.. let people continue to read/hear about massive losses of data and see what happens... rene, you also have to understand, i'm not trying to determine if the user's entire system is 'clean/valid'. i'd settle for a way of knowing that the browser/client that i'm talking to is legitimate!! -bruce -Original Message- From: Rene Brehmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 21, 2005 3:18 PM To: php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? Documented research indicate that on Tue, 21 Jun 2005 13:37:50 -0700, bruce wrote: chris... what you state is true at the extreme... but in the case of an client app, i could already extract information about the various apps that make up the client.. ie if, as in the case of IE, I was able to get information from the IE browser about various dlls that make up the browser. if these pieces of information correclt match what msoft would state should be there, then i could assume that the app was/is legitimate. BUT: That would mean that you can't take into account any plugins or extensions the user might install. And the security leak you're afraid of might not even be IN the browser program used. It might as well be a packet sniffer on the outside of the user's firewall ... and here's why. while you may not give a damm, there will be a growing chorus of people who'll want to know that the developers/sites are doing everything they can to ensure the safety of the entire transaction. in fact, i'm willing to bet that somehting like what i've been discussing will be delivered, and promoted as a security/selling point... I think it's more a matter of education and morale than anything else. You can't take responsibility for all clients not screwing up their own system. You just have to hope and trust, that when you tell your users to use this and that browser, and take this and that precaution, that they actually do it, and not install a whole bunch of crap that creates a security problem. What you're asking for is basically a way to control what users do on their own computers, and refuse them if you don't like what they've done. It's not very short of invasion of privacy. Electronic Arts already do that with their games (spy on your computer without your permission, and the refuse you to play the game you legally paid for, because you have other legally paid programs that they don't
RE: [PHP] Re: security question...??
bruce mailto:[EMAIL PROTECTED] on Wednesday, June 22, 2005 10:28 AM said: sure it can rory... i can give you a file... i create a hash of the file... if i have a process within the file that i give you that allows the file to more or less create the hash of itself, and if i can query/access the file to get the information, then i can more or less determine if the file has been changed.. But even if the file(s) you're checking haven't changed that doesn't have anything to do with determining whether or not a 3rd party program is eavesdropping on the entire conversation, stealing whatever data it wants. Go back to the wall analogy I gave earlier. You may, without a shadow of a doubt (and accurately so), know that you're speaking with a person you trust on the other side of the wall. But what you don't know, nor could you determine(!), is that there is another person standing next to the person you're talking to listening to everything you both say and writing it all down. You'd probably say, well I'll just ask the person I trust if someone else is there... But remember the rootkit? The person you trust may not even know another person is standing there so as far as the person you trust is concerned, there isn't anyone else listening. And now you're back to square one. So what if all your hashing and double checking of hashes succeeds. That doesn't change the fact that you don't have control over the client and that you can't be certain of what's happening on the client's side. Period. This thread is a joke. Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: security question...??
if i as a bank, refuse to allow you to signin to my server, because i detect that your client is not valid/legitimate, meaning i think it's been hacked, how have i trampled the rights of anyone. i haven't. will some customers run, sure.. perhaps.. will i potentially feel better. yeah. will i potentially have something that i can promote as an extra level of security that others don't have, maybe.. The banking industry is generally not slow in exploring security issues. In point of fact, I know a guy here in Australia who works as a consultant for the major banks on encryption protocols and strategies (and his encryption-related background before working privately for the banking industry is *scary*), so it should be a given that banks do care about security both generally and specifically. That having been said, you're waving the stick around by the wrong end. It is fundamentally more important to a bank that general access to customer records be protected, not to specific records relating to any one customer because of that customer's negligence. By this I mean, most of their money is invested in attempting to stop hostile attempts to gain access to customer databases at their end, not at stopping hostile attempts to gain access to customer data at the client's end. Why? Because that's where the liability lies. Follow the money. If you expose your own records by being foolish enough to run spyware-ridden browser software, this is your own issue. Again, as I mentioned before, once the data is in your hands, it's your responsibility. Behave responsibly or stupidly / ignorantly, the choice is ultimately yours. let people continue to read/hear about massive losses of data and see what happens... Again, the massive losses of data we generally hear about are not as a result of sniffer programs sitting at the client end. They're ordinarily about hackers gaining access to the data at the source, where thousands or millions of customer records can be compromised, not at the client. This doesn't mean it's not an issue, but that it's an issue that can't and won't be addressed by anything more than public awareness campaigns. Which is why I think you're wasting energy on this topic. I'd much rather see you or anyone else, for that matter, putting this care and attention into reviewing how secure your app is, even if it's for the 20th time, than wondering how you go about hypothetically doing something that can't be done, and which, to the best of anyone's knowledge, isn't going to be practically implemented by anyone any time soon. Obligatory, Oh my god, can you really believe they did that? story: From a consultancy project I was hired on to extend a retail web site. SSL encryption where customer data was being entered or viewed? Check. Efforts to negate the potential of SQL / code injection? Check. Backup strategy? Daily dump of all records using PHPMyAdmin. From a directory where SSL was not being enforced. All that customer data. All that effort to protect it from being exposed to hostile eyes. From a directory where SSL was not being enforced. Makes you want to weep. Regards, Murray -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security question...??
On 6/22/05, bruce [EMAIL PROTECTED] wrote: sure it can rory... i can give you a file... i create a hash of the file... if i have a process within the file that i give you that allows the file to more or less create the hash of itself, and if i can query/access the file to get the information, then i can more or less determine if the file has been changed.. Let me get this straight: - You give me a file containing a process, which you keep a hash of. [ I assume by 'process' you mean code to create a process. ] - Process creates hash of itself. [ which should be the same as the one created by you ] - You then access the file [ I assume you mean the hash, generated on the client ] - and determine if the file has been changed. [ by, I'm assuming, comparing the hashes. ] Assuming I understand your suggestion, you're simply checking to see if the file has been changed. How exactly does this detect hacked browsers? If the code to do the hashing is in the file you give me, then the browser used is irrelevent. The hash will be the same. If the code to do the hashing is in the browser, then anyone who hacks the browser, generally wouldn't modify the hashing code. You could conceveably hash the browsers binary, but there nothing to stop the hacked browser from simply storing and returning when requested checksum. Even if the hacked browser did execute the file correctly, it could simply replace the file access routines, with ones redirecting the file to a legitimate binary. would this approach require additional functionality.. sure but it might also require no more than a plugin... the issue is that there are multiple ways of tryng to determine if you have a legitimate file/app... 'trying' being the operative word. i hope you don't have this narrow focus with any of your customers, or in your daily job.. or you might simply need to recognize that there's a lot more that you don't know, than you do... ahh to be young! I think that applies to everyone, and is particularly irrelevent to this discussion. The fact that there are things I don't know doesn't take away from the stuff that I do, and one thing I do know is that your current suggestions are completely impractical. do some research, check some of the literature.. -bruce -Original Message- From: Rory Browne [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 6:58 AM To: [EMAIL PROTECTED] Cc: Rene Brehmer; php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? Okay Bruce: There's one very major problem with your suggestion - IT CAN NOT BE DONE. YOU CAN NOT TEST A REMOTE PIECE OF SOFTWARE TO MAKE SURE THAT THERE HAVE BEEN NO CHANGES TO IT. There are ways of checking what type of valid browser, or what type of valid Operating System, your using, but invalid or illegitimate, would return the same test results as valid or legitimate, since anybody hacking them would hack them to return the valid/legitimate results to such tests. Just incase you didn't understand me earlier - YOU CAN NOT RELIABLY TEST REMOTE SOFTWARE TO MAKE SURE THAT IT HAS NOT BEEN HACKED AND/OR CRACKED On 6/22/05, bruce [EMAIL PROTECTED] wrote: rene... the scenario that i'm envisioning could very well cause people to get ticked. but i also can easily see financial institutions starting to tell their customers, that unless your system is of a certain level, or running a certain kind of browser, that you'll get charged more to do business with them... security is an issue, and it's going to get larger. and that will require thinking about the user/client's setup.. if i as a bank, refuse to allow you to signin to my server, because i detect that your client is not valid/legitimate, meaning i think it's been hacked, how have i trampled the rights of anyone. i haven't. will some customers run, sure.. perhaps.. will i potentially feel better. yeah. will i potentially have something that i can promote as an extra level of security that others don't have, maybe.. let people continue to read/hear about massive losses of data and see what happens... rene, you also have to understand, i'm not trying to determine if the user's entire system is 'clean/valid'. i'd settle for a way of knowing that the browser/client that i'm talking to is legitimate!! -bruce -Original Message- From: Rene Brehmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 21, 2005 3:18 PM To: php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? Documented research indicate that on Tue, 21 Jun 2005 13:37:50 -0700, bruce wrote: chris... what you state is true at the extreme... but in the case of an client app, i could already extract information about the various apps that make up the client.. ie if, as in the case of IE, I was able to get information from the IE browser about various dlls that make up
Re: [PHP] Re: security question...??
Bruce, I think you missed my point here: Nomatter how secure the client's browser is, or even if he uses a custom made Client Access Program (believe me, the banks in Denmark used that approach at first because browsers weren't secure enough), it still doesn't change the fact that there may be other factors that cause the transmission to be insecure. A packet sniffer doesn't have to in any way be connected to the browser or other program used to access your server. And if the program used is made correctly (as in, not IE), you won't be able to detect whatever's running outside that program from the server side. And packet sniffers already exist in the majority of computers: firewalls, anti-virus, and network traffic monitors. They all do, or can, read the contents of the network packets going in and out of the computer. I have numerous versions of those, some of them will let me actually see the contents of each and every network packet ... Packet sniffers exist that'll let you monitor the network traffic on a remote computer, without even have access to that computer (one of my friends did it to me just to show how easy it is). So even if your server could see that the program your client uses is as secure as can be, there isn't any way possible that you'll be able to see if the connection between you and the client is tapped or not... My bank in Denmark use custom encryption plugins for the browser because the built-in encryption system isn't good enough. Their system is based upon HTML websites only because it's more comfortable to use, but without their custom plugin and the digital key I have to install to make it work, the online banking website is completely inaccessible. Their system don't even use normal cookies because it'd leave footprints on your computer. But it still doesn't change the fact that it still communicates through normal HTTP and TCP commands, and that the packets are still readable, although encrypted... Rene Documented research indicate that on Wed, 22 Jun 2005 06:00:48 -0700, bruce wrote: rene... the scenario that i'm envisioning could very well cause people to get ticked. but i also can easily see financial institutions starting to tell their customers, that unless your system is of a certain level, or running a certain kind of browser, that you'll get charged more to do business with them... security is an issue, and it's going to get larger. and that will require thinking about the user/client's setup.. if i as a bank, refuse to allow you to signin to my server, because i detect that your client is not valid/legitimate, meaning i think it's been hacked, how have i trampled the rights of anyone. i haven't. will some customers run, sure.. perhaps.. will i potentially feel better. yeah. will i potentially have something that i can promote as an extra level of security that others don't have, maybe.. let people continue to read/hear about massive losses of data and see what happens... rene, you also have to understand, i'm not trying to determine if the user's entire system is 'clean/valid'. i'd settle for a way of knowing that the browser/client that i'm talking to is legitimate!! -bruce -- Rene Brehmer aka Metalbunny We have nothing to fear from free speech and free information on the Internet, but pop-up advertising! http://metalbunny.net/ My little mess of things... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: security question...??
but chris... go back and look at the entire thread... i never stated that i wanted to be able to know whether the entire system is secure on the client's end.. i stated that i wanted to be able to know if the client that i'm dealing with is legitimate.. keep the conversation apples to apples... i've intentionally constrained the focus of this thread.. the fact that you've taken the thread in another direction is your issue... -bruce -Original Message- From: Chris W. Parker [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 11:01 AM To: [EMAIL PROTECTED]; Rory Browne; php-general@lists.php.net Subject: RE: [PHP] Re: security question...?? bruce mailto:[EMAIL PROTECTED] on Wednesday, June 22, 2005 10:28 AM said: sure it can rory... i can give you a file... i create a hash of the file... if i have a process within the file that i give you that allows the file to more or less create the hash of itself, and if i can query/access the file to get the information, then i can more or less determine if the file has been changed.. But even if the file(s) you're checking haven't changed that doesn't have anything to do with determining whether or not a 3rd party program is eavesdropping on the entire conversation, stealing whatever data it wants. Go back to the wall analogy I gave earlier. You may, without a shadow of a doubt (and accurately so), know that you're speaking with a person you trust on the other side of the wall. But what you don't know, nor could you determine(!), is that there is another person standing next to the person you're talking to listening to everything you both say and writing it all down. You'd probably say, well I'll just ask the person I trust if someone else is there... But remember the rootkit? The person you trust may not even know another person is standing there so as far as the person you trust is concerned, there isn't anyone else listening. And now you're back to square one. So what if all your hashing and double checking of hashes succeeds. That doesn't change the fact that you don't have control over the client and that you can't be certain of what's happening on the client's side. Period. This thread is a joke. Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: security question...??
rene.. you've grapsed the problem/issue, as have most. all i said was that i've started to think about the issue of security as also meaning i have to start thinking about the client. just as users have had to start to think about 'is the site i'm looking at, really the site i want/should be looking at?' i'm not thinking of how to solve all the issues surounding the client machine.. nor am i simply willing to say i'm just going to focus only on the server app... but, ultimately, if this approach were introduced/used in the market, it would be up to the market to dscide... and let's be real, there will never be a solution for any problem that satifies everyone! that's life.. peace.. -bruce -Original Message- From: Rene Brehmer [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 2:55 PM To: php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? Bruce, I think you missed my point here: Nomatter how secure the client's browser is, or even if he uses a custom made Client Access Program (believe me, the banks in Denmark used that approach at first because browsers weren't secure enough), it still doesn't change the fact that there may be other factors that cause the transmission to be insecure. A packet sniffer doesn't have to in any way be connected to the browser or other program used to access your server. And if the program used is made correctly (as in, not IE), you won't be able to detect whatever's running outside that program from the server side. And packet sniffers already exist in the majority of computers: firewalls, anti-virus, and network traffic monitors. They all do, or can, read the contents of the network packets going in and out of the computer. I have numerous versions of those, some of them will let me actually see the contents of each and every network packet ... Packet sniffers exist that'll let you monitor the network traffic on a remote computer, without even have access to that computer (one of my friends did it to me just to show how easy it is). So even if your server could see that the program your client uses is as secure as can be, there isn't any way possible that you'll be able to see if the connection between you and the client is tapped or not... My bank in Denmark use custom encryption plugins for the browser because the built-in encryption system isn't good enough. Their system is based upon HTML websites only because it's more comfortable to use, but without their custom plugin and the digital key I have to install to make it work, the online banking website is completely inaccessible. Their system don't even use normal cookies because it'd leave footprints on your computer. But it still doesn't change the fact that it still communicates through normal HTTP and TCP commands, and that the packets are still readable, although encrypted... Rene Documented research indicate that on Wed, 22 Jun 2005 06:00:48 -0700, bruce wrote: rene... the scenario that i'm envisioning could very well cause people to get ticked. but i also can easily see financial institutions starting to tell their customers, that unless your system is of a certain level, or running a certain kind of browser, that you'll get charged more to do business with them... security is an issue, and it's going to get larger. and that will require thinking about the user/client's setup.. if i as a bank, refuse to allow you to signin to my server, because i detect that your client is not valid/legitimate, meaning i think it's been hacked, how have i trampled the rights of anyone. i haven't. will some customers run, sure.. perhaps.. will i potentially feel better. yeah. will i potentially have something that i can promote as an extra level of security that others don't have, maybe.. let people continue to read/hear about massive losses of data and see what happens... rene, you also have to understand, i'm not trying to determine if the user's entire system is 'clean/valid'. i'd settle for a way of knowing that the browser/client that i'm talking to is legitimate!! -bruce -- Rene Brehmer aka Metalbunny We have nothing to fear from free speech and free information on the Internet, but pop-up advertising! http://metalbunny.net/ My little mess of things... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: security question...??
bruce mailto:[EMAIL PROTECTED] on Wednesday, June 22, 2005 3:17 PM said: but chris... go back and look at the entire thread... i never stated that i wanted to be able to know whether the entire system is secure on the client's end.. i stated that i wanted to be able to know if the client that i'm dealing with is legitimate.. Then what is the point? And why are you stopping your extra efforts at the client's web browser? What criteria did you use to determine that the client's webbrowser is as far as your duties should extend? You should extend it to include their entire computer. While you're at it make sure that the person doesn't write their password(s) down or give it away after being tempted with a chocolate bar. Also make sure the hardware is physically locked down too and make sure there are no keyloggers in between the keyboard and the PC. Ugh. Bruce, plain and simple your idea is not going to work and it's a waste of time. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: security question...??
On Wed, June 22, 2005 3:27 pm, bruce said: rene.. you've grapsed the problem/issue, as have most. all i said was that i've started to think about the issue of security as also meaning i have to start thinking about the client. just as users have had to start to think about 'is the site i'm looking at, really the site i want/should be looking at?' It's remotely possible that you could get an RFC going about software installation generating an SSL certificate on the client, tied to the client's hardware signature[s]/ID[s], digitally signed by the software installation only if the MD5 hash of the software matched an expected value, and... No, still too easy to hack, if the Bad Guy can change out the binary of the browser in the first place. I think everybody here is thinking about what you are saying, and they're all saying It won't work So you can either be the next Einstein and prove them wrong, or it really won't work. Take your pick. At any rate, it's not a PHP question, and you should probably take it to a Security RFC type of forum, please. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security question...??
However secure you try to make a web application, even with encryption, it still does not hinder anyone from putting a packet sniffer on your client and grab whatever sensitive information you send out. And if a hacker really wanted to get hold of your sensitive information, he wouldn't actually have to use a typical browser or anything similar to do it, nor is it likely he would. There's nothing to hinder for talking to your HTTP server using manually entered commands in a telnet client. My information 'bout the US approach to encryption may be a little out of date, but for the longest, using anything stronger than 40 bit encryption was illegal, unless the CIA knew the extra bits above 40 (thus Philip Zimmermann got arrested for violating the weapons law when he created PGP). All that mess did change something, but there's still limitations to what you can do in regards to encryption, that don't exist in any other country. 9/11 didn't exactly help that in any way. But nevertheless, for every way you can come up with ensuring that your client is using a secure application, there's atleast as many ways to make a program that fools your tests, and then you're back to where you came from. The thing I said about where your responsibility ends, is simply that when you tell a client to use this and that software to access the data in your remote application, then you can't really prevent them from using software that they think is right, but isn't. There is no reliable way, with current technologies, of determining whether or not a client's software is what it says it is or not. I think it falls under implicit trust ... It reminds me of those websites that checks for the version of your browser, and refuses to work if you don't have one they like, that falls completely short when you visit them with Firefox because it has Mozilla and ver. 1 in its ID string, and the sites think it's a Netscape 1 ... point being that you can't blindly trust what the client software tells you ... I don't honestly see any way of doing what you want, without also being able to see how it can be fooled... Rene Documented research indicate that on Mon, 20 Jun 2005 17:50:25 -0700, bruce wrote: rene.. from my perspective, i strongly disagree... if you're going to be writing apps that deal with sensitive information, you better damm well give some thought as to how secure the client is, or even if the client is actually valid! while i'm not precisely sure as to how you'd go about ensuring that the client is indeed real/valid, and not faked, there are some reasonable approaches that the vendor/manufacturer could take, or make available that could go a good way towards satisfying the issue somewhat... and creating a secure client/server connection that only the two parties (server/client) can listen to is not illegal in the US.. i'm not sure where you get your information.. but my point was not regarding tha actual communicatino pipe/wire. there are already methods of securing the wire conversation betwen the server/client. i'm concerned with being reasonably sure that the client i'm talking to is indeed a valid/real client. IE, if it identifies itself as IE, then it actually is IE, and not some spoofed app, that acts like IE, that might be sending data to who knows where... -bruce -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: security question...??
(thus Philip Zimmermann got arrested for violating the weapons law when he created PGP) I thought he got arrested because he exported PGP out of the US, not because he created it. He was told that PGP could not leave the US via any electronical form, compiled or uncompiled, because of the encryption level. He didn't break that condition and got it out via a book and someone outside the US scanned in the book and compiled the source code, but they arrested him anyhow. Probably some urban myth that I heard somewhere. As for the browser topic, you cannot control what the client browser is, or whether it has any naughty plugins. The responsibility is on the user, once the data has left the server via HTTP. Didn't the UK banks try to implement something like that for the online banking, you could only use Internet Explorer, which sparked a debate in the Linux/Unix world. This was easily spoofed. -Original Message- From: Rene Brehmer [mailto:[EMAIL PROTECTED] Sent: 21 June 2005 09:12 To: php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? * This e-mail has been received by the Revenue Internet e-mail service. * However secure you try to make a web application, even with encryption, it still does not hinder anyone from putting a packet sniffer on your client and grab whatever sensitive information you send out. And if a hacker really wanted to get hold of your sensitive information, he wouldn't actually have to use a typical browser or anything similar to do it, nor is it likely he would. There's nothing to hinder for talking to your HTTP server using manually entered commands in a telnet client. My information 'bout the US approach to encryption may be a little out of date, but for the longest, using anything stronger than 40 bit encryption was illegal, unless the CIA knew the extra bits above 40 (thus Philip Zimmermann got arrested for violating the weapons law when he created PGP). All that mess did change something, but there's still limitations to what you can do in regards to encryption, that don't exist in any other country. 9/11 didn't exactly help that in any way. But nevertheless, for every way you can come up with ensuring that your client is using a secure application, there's atleast as many ways to make a program that fools your tests, and then you're back to where you came from. The thing I said about where your responsibility ends, is simply that when you tell a client to use this and that software to access the data in your remote application, then you can't really prevent them from using software that they think is right, but isn't. There is no reliable way, with current technologies, of determining whether or not a client's software is what it says it is or not. I think it falls under implicit trust ... It reminds me of those websites that checks for the version of your browser, and refuses to work if you don't have one they like, that falls completely short when you visit them with Firefox because it has Mozilla and ver. 1 in its ID string, and the sites think it's a Netscape 1 ... point being that you can't blindly trust what the client software tells you ... I don't honestly see any way of doing what you want, without also being able to see how it can be fooled... Rene Documented research indicate that on Mon, 20 Jun 2005 17:50:25 -0700, bruce wrote: rene.. from my perspective, i strongly disagree... if you're going to be writing apps that deal with sensitive information, you better damm well give some thought as to how secure the client is, or even if the client is actually valid! while i'm not precisely sure as to how you'd go about ensuring that the client is indeed real/valid, and not faked, there are some reasonable approaches that the vendor/manufacturer could take, or make available that could go a good way towards satisfying the issue somewhat... and creating a secure client/server connection that only the two parties (server/client) can listen to is not illegal in the US.. i'm not sure where you get your information.. but my point was not regarding tha actual communicatino pipe/wire. there are already methods of securing the wire conversation betwen the server/client. i'm concerned with being reasonably sure that the client i'm talking to is indeed a valid/real client. IE, if it identifies itself as IE, then it actually is IE, and not some spoofed app, that acts like IE, that might be sending data to who knows where... -bruce -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php This message has been delivered to the Internet by the Revenue Internet e-mail service * -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: security question...??
Why don't you try to get interactivity with ID machin which is unique, or with mac address. David Le Tue, 21 Jun 2005 12:50:23 +0200, Shaw, Chris - Accenture [EMAIL PROTECTED] a écrit: (thus Philip Zimmermann got arrested for violating the weapons law when he created PGP) I thought he got arrested because he exported PGP out of the US, not because he created it. He was told that PGP could not leave the US via any electronical form, compiled or uncompiled, because of the encryption level. He didn't break that condition and got it out via a book and someone outside the US scanned in the book and compiled the source code, but they arrested him anyhow. Probably some urban myth that I heard somewhere. As for the browser topic, you cannot control what the client browser is, or whether it has any naughty plugins. The responsibility is on the user, once the data has left the server via HTTP. Didn't the UK banks try to implement something like that for the online banking, you could only use Internet Explorer, which sparked a debate in the Linux/Unix world. This was easily spoofed. -Original Message- From: Rene Brehmer [mailto:[EMAIL PROTECTED] Sent: 21 June 2005 09:12 To: php-general@lists.php.net Subject: Re: [PHP] Re: security question...?? * This e-mail has been received by the Revenue Internet e-mail service. * However secure you try to make a web application, even with encryption, it still does not hinder anyone from putting a packet sniffer on your client and grab whatever sensitive information you send out. And if a hacker really wanted to get hold of your sensitive information, he wouldn't actually have to use a typical browser or anything similar to do it, nor is it likely he would. There's nothing to hinder for talking to your HTTP server using manually entered commands in a telnet client. My information 'bout the US approach to encryption may be a little out of date, but for the longest, using anything stronger than 40 bit encryption was illegal, unless the CIA knew the extra bits above 40 (thus Philip Zimmermann got arrested for violating the weapons law when he created PGP). All that mess did change something, but there's still limitations to what you can do in regards to encryption, that don't exist in any other country. 9/11 didn't exactly help that in any way. But nevertheless, for every way you can come up with ensuring that your client is using a secure application, there's atleast as many ways to make a program that fools your tests, and then you're back to where you came from. The thing I said about where your responsibility ends, is simply that when you tell a client to use this and that software to access the data in your remote application, then you can't really prevent them from using software that they think is right, but isn't. There is no reliable way, with current technologies, of determining whether or not a client's software is what it says it is or not. I think it falls under implicit trust ... It reminds me of those websites that checks for the version of your browser, and refuses to work if you don't have one they like, that falls completely short when you visit them with Firefox because it has Mozilla and ver. 1 in its ID string, and the sites think it's a Netscape 1 ... point being that you can't blindly trust what the client software tells you ... I don't honestly see any way of doing what you want, without also being able to see how it can be fooled... Rene Documented research indicate that on Mon, 20 Jun 2005 17:50:25 -0700, bruce wrote: rene.. from my perspective, i strongly disagree... if you're going to be writing apps that deal with sensitive information, you better damm well give some thought as to how secure the client is, or even if the client is actually valid! while i'm not precisely sure as to how you'd go about ensuring that the client is indeed real/valid, and not faked, there are some reasonable approaches that the vendor/manufacturer could take, or make available that could go a good way towards satisfying the issue somewhat... and creating a secure client/server connection that only the two parties (server/client) can listen to is not illegal in the US.. i'm not sure where you get your information.. but my point was not regarding tha actual communicatino pipe/wire. there are already methods of securing the wire conversation betwen the server/client. i'm concerned with being reasonably sure that the client i'm talking to is indeed a valid/real client. IE, if it identifies itself as IE, then it actually is IE, and not some spoofed app, that acts like IE, that might be sending data to who knows where... -bruce -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php This message has been
Re: [PHP] Re: security question...??
* david forums [EMAIL PROTECTED]: Why don't you try to get interactivity with ID machin which is unique, or with mac address. MAC address wouldn't work if the user is behind a proxy. -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
