Re: Security in displaying arbitrary HTML
On Thu, 27 Apr 2000, Marc Slemko wrote:
Can you be more specific about why you say that? If I set an encrypted,
short-lived cookie upon validated authentication, why is that any less
secure than any of the other approaches you mentioned?
It isn't necessarily any "less secure", but you just have to understand
and properly manage what it opens you up to. I'm not suggesting
alternatives because they are very limited.
I just wrote an article on XSS (Cross-Site Scripting -- I use "XSS"
instead of "CSS" because CSS means Cascading Style Sheets to most Web
developers and designers) for Webmonkey:
http://hotwired.lycos.com/webmonkey/00/18/index3a.html
If you want to see what sort of stuff the XSS problem opens you up for,
just try appending ?tw=scriptalert("aha!");/script to the URL above.
Both the Apache folks and Microsoft security have detailed several ways
in which this attack can be much, much, worse than a single Javascript
popup. There are links to resources at the end of the article.
Myself, I've been amusing myself with this:
http://hotwired.lycos.com/webmonkey/00/18/index3a_page6.html?tw=%3CIMG%20SRC%3Dhttp%3A%2F%2Fbarneyonline.com%2Fimages%2Fbab3.gif%3E
Cheers,
Steve
--
tired of being an underappreciated functionary in a soulless machine?
hesketh.com is hiring: http://hesketh.com/careers/
Re: Security in displaying arbitrary HTML
On Thu, 27 Apr 2000, Vivek Khera wrote:
Why on earth would you take user input and output it verbatim to your
pages? Rule number 1 of developing a web site is to never trust the
user's input values. *Always* validate it against what you're
expecting.
I guess someone had better tell the folks at Vignette that. Well, and
the folks at all the major search engines. And the portals. And anyone
using a search box that redisplays the query on every results page...
Before I wrote the article, I checked out about fifty major portals
and search engines, and only about a third did any filtering on the
input; some did filtering, but poorly; and a good third of them just
redisplayed the query verbatim. Try searching for
scriptalert("aha");/script
at your favorite search engine. The problem is, well, pretty widespread.
Steve
--
tired of being an underappreciated functionary in a soulless machine?
hesketh.com is hiring: http://hesketh.com/careers/
RE: best way to call traceroute
On Fri, 7 Apr 2000, Karyn Ulriksen wrote: One of the reasons that I always like the nph- construction is that is showed the traceroute 'live' like it would from a console. Last I checked perl doesn't show the traceroute result until the sessions complete which could be a long time if there is trouble in the trace. Did you find a way to get past that? http://hesketh.net/traceroute?view-source=1 $r-rflush() works fine for me. Steve, welcoming feedback -- tired of being an underappreciated functionary in a soulless machine? hesketh.com is hiring: http://hesketh.com/careers/
Re: best way to call traceroute
On Fri, 7 Apr 2000, Sam Carleton wrote: I want to call traceroute to the remote_host from within a mod_perl script, being a C/C++ programmer I don't the best way to do that. Is there a traceroute object I could use? If so, how? Otherwise how do I run traceroute from within a perl script? I'm getting ready to port an old and somewhat clunky traceroute CGI script to mod_perl, mostly to avoid the horrid 'nph-' construction. If you'd like I can make the source available. Steve -- tired of being an underappreciated functionary in a soulless machine? hesketh.com is hiring: http://hesketh.com/careers/
Re: [OT] Standard country codes/names, where to get them?
On Wed, 5 Apr 2000, Vivek Khera wrote: "ELM" == Erich L Markert [EMAIL PROTECTED] writes: ELM I remember being able to download a text file (I think from W3C) that ELM contained a listing of international standard country names and codes Hmmm. I don't recall from where I got it. I recall it being an ISO standard document. But all I have left of it is a Perl module that just defines a hash mapping the country code to its full name. It's only 6k long, so if anyone wants it, I'll post it. I use: ftp://ftp.ripe.net/iso3166-countrycodes HTH, Steve -- tired of being an underappreciated functionary in a soulless machine? hesketh.com is hiring: http://hesketh.com/careers/
efficiency questions (templates, regexes, db calls)
Hi, gang. I'm working on my first serious mod_perl app, and have a few
questions regarding efficiency -- basically looking for traps I may not
have internalized after reading the mod_perl_traps page and so forth.
I'm developing a site that will use MySQL on the backend to store some
info related to goofy timewasting projects (e.g., name, url, contributor,
date last updated, description, etc.) The idea is that there really needs
to be a site where I can list all my goofy timewasting projects, and I
want other people to submit their stuff, too. Sort of a freshmeat for the
random non-commercial stuff that abounds on the 'Net, but which seems to
be neglected in this weblog age, or doesn't get much notice unless it's an
Open Source [tm] project with millions of contributors. :)
Anyway. I have been designing the templates for each class of page on the
site (main project list, individual project detail, admin forms, and so
forth). I want to populate each template with data from the db. I don't
particularly want to use EmbPerl; I'd rather read the templates at init
time and parse in the db data when the page is to be returned. Are there
any traps I should be aware of? I only have four or five relatively small
templates, so memory consumption shouldn't be a big deal. From what I
understand from reading the Guide, these vars will likely be shared,
anyway, right, if I make the vars global and populate them at startup?
I figure I'll put the actual perl modules in lib/perl/, and put the
templates I'm going to use in directories under docroot that correspond
to the handler I've defined, just for sanity's sake. So,
Location /hello
SetHandler perl-script
PerlHandler Apache::Hello
/Location
would use templates found in $docroot/hello, and so on. But the actual
templates would be loaded at httpd init time, and kept around, then
I'll perform substitutions on them based on user input or database info.
I know about using /o to compile a regex. The embedded tokens in the
templates won't change, so this will probably work fine, right?
(e.g.:
!--( $variable )--
can be replaced by the variable's value on the fly, without hitting
the disk to open the template file:
my $variable = "something I got from a form or db";
my @lines = split($GLOBAL_VAR_CONTAINING_TEMPLATE_GUTS);
while(@lines) {
s/!--( $variable )--/$variable/o;
print;
}
I know to use persistent db connections and pre-load DBI. I know to
tweak Max* to maximize performance. I'm just wondering if there's any
other obvious traps that come to mind. Thanks in advance.
Steve
Re: Another IE5 complaint
On Tue, 23 Nov 1999, Ruben I Safir wrote: LINK REL="SHORTCUT ICON" href="/path/to/favicon.ico" Is this sort of thing implimented in Netscape? Is rev and rel implemented in any fashion? It's not implemented for favicon, no. But LINK REL is supported by Navigator for external CSS stylesheets, for example. That's the only use I know of, though. Steve -- business: http://hesketh.com ...custom medium- to large-scale web sites the book: http://dhtml-guis.com ...Building Dynamic HTML GUIs from IDG punditry: http://a.jaundicedeye.com ...negative forces have value personal: http://hesketh.com/schampeo/ ...info, projects, random stuff
Re: Another IE5 complaint
On Fri, 1 Oct 1999, Joe Pearson wrote: Maybe everyone already knows this, but I just discovered that whenever a IE5 user visits a page in their "Favorites", IE5 also trys to GET favicon.ico from the same site. Therefor I have hundreds of "File does not exist:" errors in my log file. Oh, that's an easy fix. If you're using Apache, just stick a redirect into your config so that favicon.ico requests are redirected to the microsoft.com site. RedirectMatch permanent ^.*favicon.ico$ http://www.microsoft.com/please/fix/your/stupid/browser Barring that, redirect it to your own favicon file (preferably not named 'favicon.ico', though, unless you /like/ infinite loops.) You'll need to grab /all/ requests for favicon.ico, though, as IE is so dumb it looks for the file in any subdirectory as well, so if the bookmark is for "/some/dir" it will look for "/some/dir/favicon.ico", and so forth. Steve
