pas-dev Mailing List for Perl Application Server (Page 14)
Status: Beta
Brought to you by:
mortis
You can subscribe to this list here.
2002 |
Jan
|
Feb
(6) |
Mar
(19) |
Apr
(3) |
May
(147) |
Jun
(6) |
Jul
(4) |
Aug
(12) |
Sep
(1) |
Oct
(12) |
Nov
(23) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(4) |
Feb
(12) |
Mar
(13) |
Apr
(16) |
May
(28) |
Jun
(9) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
(84) |
Dec
(25) |
2004 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
From: Kyle R . B. <mo...@vo...> - 2002-05-27 19:05:46
|
> I've been having problems with included files today. I recently updated my PAS > directory and none of the included files were showing up. I tracked it down to > inside resolve_includes(). I changed this: > > $file = > $ENV{'PAS_BASE'}.'/'.$self->config()->get('pas.documentRoot').'/'.$file; > > > to this: > > $file = $self->config()->get('pas.documentRoot').'/'.$file; That's part of this block, right?: unless('/' eq substr($file,0,1)) { $file = $self->pwd().'/'.$file; } else { $file = $ENV{'PAS_BASE'}.'/'.$self->config()->get('pas.documentRoot').'/'.$file; } I think the point of that if/else (ok, unless/else) is to use the file path as specified, if it is an absolute path (starts with a '/'), otherwise, assume it's pathed the document root. The problem is obviously in the else block -- we need to check the value of pas.documentRoot to see if it starts with a '/', and prefix it with PAS_BASE otherwise. Maybe this should be a function in the Environment package? Do we already have a method that returns the document root somewhere? Maybe we should add the proper logic to it, and then update the line above to use it. > And it works. On another box (internal production environment), we have version > 1.12 of the Compiler.pm checked out and it works fine. Actually, it looks like > we had a similar problem back then: > > #$file = $ENV{'PAS_BASE'}.'/'.$self->config()->get('pas.documentRoot').'/'.$file; > $file = $self->config()->get('pas.documentRoot').'/'.$file; > > It was solved the same exact way. However, mortis checked it in with the > $ENV{'PAS_BASE'} for 1.13 (we're on 1.19 in case anyone is wondering). > > I guess we have to figure out how were're going to do this. I think it should > be off of pas.documentRoot. I don't know why $ENV{'PAS_BASE'} is in there. PAS_BASE is there, becuase we want the flexibility for the the doc root to be either relative to PAS_BASE, or absolutely pathed. How would you guys like to do this? Kyle > Let me know if you want me to check it in or if someone else wants to make the > change. > > Justin > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Pas-dev mailing list > Pa...@li... > https://lists.sourceforge.net/lists/listinfo/pas-dev -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kaare R. <ka...@ka...> - 2002-05-27 18:04:16
|
Hi > Give it time :) I dont think any of us (current developers) use apache > 2.0. Didn't think so - but it had to be tried :-) > 2. Unable to compile the page in the psp-cache dir. Bingo. #1 was fixed (found it in Apache's error log) but #2 didn't show up in the log... Time to look into the example suite ;-) Well, do you have some more extensive examples? I'd like to put some questions here. Hope it's OK. For starters, I was searching for an environment that would support the use og modules in Perl. This is in contrast with embedding tags into html code. It can be done, but I think it's dificult in Interchange, and also EmbPerl and Mason. The natural way to build a Financial Application like Freemoney is with these layers: 1. Database functionality. Constraints, triggers, stored procedures etc. 2. Database layer in Perl. Insert, update, delete and retrieval. 3. Functionality layer in Perl (business rules etc) 4. Presentation layer. can access layer 2 and 3. How much can pas provide? -- Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582 Kaki Data tshirts, merchandize Fax: 3816 2501 Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk 2000 Frederiksberg Lørdag 11.00-17.00 Email: ka...@ka... |
From: Mental <Me...@Ne...> - 2002-05-25 13:42:25
|
On Sat, May 25, 2002 at 01:08:29PM +0200, Kaare Rasmussen wrote: > I tried to install pas last night. > > Well, it doesn't work on Apache 2.0 and mod_perl 2.0. It could be expected, > but I had to try :-) > Give it time :) I dont think any of us (current developers) use apache 2.0. > Installed on another server. I think I used all defaults and installed pas in > /home/pas, but the examples give me > > Pas: Internal Server Error > Exception: > Org::Bgw::Pas::RequestHandler=HASH(0x8568740) > > and a list of environment variables, @INC and %INC. > > I'm not sure if I struck a FAQ or what? > Look in pas.log and apaches error log. But if I had to take a guess, I'd say that the requesthandler is either: 1. Unable to open pas.log for writing. 2. Unable to compile the page in the psp-cache dir. 3. Both. If the user apache runs as cannot update/creat those files, paswwill not work. Hope that helps you track it down. -- Mental (Me...@Ne...) I broke my arm trying to fold a bed. It wasn't the kind that folds. --Steven Wright GPG public key: http://www.neverlight.com/Mental.asc |
From: Kaare R. <ka...@ka...> - 2002-05-25 11:08:48
|
I tried to install pas last night. Well, it doesn't work on Apache 2.0 and mod_perl 2.0. It could be expected, but I had to try :-) Installed on another server. I think I used all defaults and installed pas in /home/pas, but the examples give me Pas: Internal Server Error Exception: Org::Bgw::Pas::RequestHandler=HASH(0x8568740) and a list of environment variables, @INC and %INC. I'm not sure if I struck a FAQ or what? -- Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582 Kaki Data tshirts, merchandize Fax: 3816 2501 Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk 2000 Frederiksberg Lørdag 11.00-17.00 Email: ka...@ka... |
From: Justin B. <ju...@le...> - 2002-05-24 21:19:35
|
I've been having problems with included files today. I recently updated my PAS directory and none of the included files were showing up. I tracked it down to inside resolve_includes(). I changed this: $file = $ENV{'PAS_BASE'}.'/'.$self->config()->get('pas.documentRoot').'/'.$file; to this: $file = $self->config()->get('pas.documentRoot').'/'.$file; And it works. On another box (internal production environment), we have version 1.12 of the Compiler.pm checked out and it works fine. Actually, it looks like we had a similar problem back then: #$file = $ENV{'PAS_BASE'}.'/'.$self->config()->get('pas.documentRoot').'/'.$file; $file = $self->config()->get('pas.documentRoot').'/'.$file; It was solved the same exact way. However, mortis checked it in with the $ENV{'PAS_BASE'} for 1.13 (we're on 1.19 in case anyone is wondering). I guess we have to figure out how were're going to do this. I think it should be off of pas.documentRoot. I don't know why $ENV{'PAS_BASE'} is in there. Let me know if you want me to check it in or if someone else wants to make the change. Justin |
From: Kyle R . B. <mo...@vo...> - 2002-05-24 19:36:39
|
http://pas.sourceforge.net/docs/pas-hierarchy.png I had some trouble with not follwing all the parts of the inheritence tree before. Now the graph is more representative of how things really are. Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kyle R . B. <mo...@vo...> - 2002-05-24 19:14:57
|
> You could look into neato or dot. I'm not quite sure what you want stuff > to look like, but it might be useful. > > The syntax is easy, and you can output your diagrams in a variety of > formats. > > diagraph "Org::Bgw::Pas" > { > "something" -> "somethingelse" [dir=both len=2]; > } OMG! Why didn't you tell me about that before! http://pas.sourceforge.net/docs/pas-hierarchy.png :o Thanks! It's huge and ugly, but then again, It's my first autogenerated inheritence hierarchy from Perl code. :) I'll check in the program that created that from the sources...the code is a quick hack, but it does the job...we'll have to clean it up later. I wonder how hard it'll be to build actual UML out of it...it should be easy to figure out methods (private starting with an '_'), so we could easily add those to the object diagrams... Any advice on usign DOT to do more than just the simple boxes? Awesome dude, absolutely awesome. Thanks for pointing that out. Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kaare R. <ka...@ka...> - 2002-05-24 19:09:19
|
> - system, and netwrok diagrams > - UML - class diagrams, etc. Maybe argo-UML? http://argouml.tigris.org/ http://www.gentleware.com/products/poseidonDE.php3 -- Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582 Kaki Data tshirts, merchandize Fax: 3816 2501 Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk 2000 Frederiksberg Lørdag 11.00-17.00 Email: ka...@ka... |
From: Mental <me...@ne...> - 2002-05-24 18:33:18
|
On Fri, 2002-05-24 at 14:11, Kyle R . Burton wrote: > As part of the documentation push I'm getting to the piont where I want t= o > start drawing some diagrams. The output format will need to probably be = PNG, > or PS, as the diagrams will be linked from the sgml documents. >=20 > Anyone have any suggestions for what I should use? I've thought about Di= a, > but it's not exactly what I'm after. The kinds of diagramming I'm talkin= g > about are of the type you would typicly find in printed manuals or books: > You could look into neato or dot. I'm not quite sure what you want stuff to look like, but it might be useful. The syntax is easy, and you can output your diagrams in a variety of formats. diagraph "Org::Bgw::Pas" { "something" -> "somethingelse" [dir=3Dboth len=3D2]; } The diagram files would be small enough to check into cvs, and you shouldnt have a hard time then generating images or whatever. From the dot man page: DESCRIPTION dot draws directed graphs. It works well on DAGs and other graphs that can be drawn as hierarchies. It reads attributed graph files and writes drawings. By default, the output format dot is the input file with layout coor=AD dinates appended. To generate PostScript, use the -Tps option. Other choices are -Tmif (FrameMaker graphics), -Thpgl (HP pen plotters), and -Tpcl (Laserjet printers), -Tgif (pixel graphics), -Timap, and -Tismap (imagemap files for httpd servers that mark out rectangles for each node that has a non-null URL attribute.). --=20 Mental (Me...@Ne...) |
From: Kyle R . B. <mo...@vo...> - 2002-05-24 18:11:32
|
As part of the documentation push I'm getting to the piont where I want to start drawing some diagrams. The output format will need to probably be PNG, or PS, as the diagrams will be linked from the sgml documents. Anyone have any suggestions for what I should use? I've thought about Dia, but it's not exactly what I'm after. The kinds of diagramming I'm talking about are of the type you would typicly find in printed manuals or books: - system, and netwrok diagrams - UML - class diagrams, etc. Should I just use GIMP? If I do, I'm afraid that the source image files will be large enough that I won't want to have them as part of the CVS archive -- I'm still running dial-up at home. That does rasie the question of wether we want to have the documentation as a seperate CVS archive/project. Any advice or feedback would be appreciated. Thanks, Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Mental <me...@ne...> - 2002-05-24 15:47:04
|
On Fri, 2002-05-24 at 11:14, Mental wrote: > Hello. A relative path in the config file breaks the page objects. > Inside RequestHandler.pm, in get_package_for_page_object it does this: > > trying /usr/local/pas/pas/../neverlight/htdocs/examples/TestPage eq > /usr/local/pas/neverlight/htdocs/examples/TestPage > > Naturally, it doesnt work. If I use an absolute path, I'm good. Should I > write a method that 'normalizes' the path? Should we just document the > config file is supposed to use absolute paths? > Well, its documented to work with relative paths, so I fixed the code. :) -- Mental (Me...@Ne...) |
From: Mental <me...@ne...> - 2002-05-24 15:13:56
|
Hello. A relative path in the config file breaks the page objects. Inside RequestHandler.pm, in get_package_for_page_object it does this: trying /usr/local/pas/pas/../neverlight/htdocs/examples/TestPage eq /usr/local/pas/neverlight/htdocs/examples/TestPage Naturally, it doesnt work. If I use an absolute path, I'm good. Should I write a method that 'normalizes' the path? Should we just document the config file is supposed to use absolute paths? -- Mental (Me...@Ne...) |
From: Kyle R . B. <mo...@vo...> - 2002-05-23 19:28:55
|
> The pod files in cvs are 1 year old. Are they still correct? No, they were not. Thanks for pointing that out. We probably shouldn't even have the POD HTML files checked in since they're generated. I regenerated them (type make in the pas/docs/ directory to update them) and even updated them on the project website: http://pas.sourceforge.net/docs/pod/ They're alot more extensive now - more coverage for more objects. Thanks, Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kaare R. <ka...@ka...> - 2002-05-23 19:22:39
|
The pod files in cvs are 1 year old. Are they still correct? -- Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582 Kaki Data tshirts, merchandize Fax: 3816 2501 Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk 2000 Frederiksberg Lørdag 11.00-17.00 Email: ka...@ka... |
From: Kyle R . B. <mo...@vo...> - 2002-05-23 16:22:36
|
The sgml files are in the docs directory - so far I have only started converting what little there was of the the admin guide, so there's not much there yet. http://pas.sourceforge.net/docs/administratorsManual/ http://pas.sourceforge.net/docs/administratorsManual/manual/book1.html It's in PS, PDF, and HTML formats. Wow that's powerful. I still don't really understand how the tools work, but they run for now and produce nice looking output, so I'll take it. :) I have a feeling that the documentation will drive how much Pas gets used... Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kyle R . B. <mo...@vo...> - 2002-05-23 15:50:08
|
> > _Great_ idea. Now we just need a way of re-encoding specific tags for > > the convinience of our users... > > > > my $decoder = Org::Bgw::Pas::HTML::EntityDecoder->new( > > a => [qw( href name alt )], > > img => [qw( src alt height width )], > > pre => [qw()], > > code => [qw()], > > p => [qw()], > > font => [qw()], > > super => [qw()] > > ); > > my $discussionMessage = $decoder->decode( $self->query()->param('message') ); > > > > I'm kinda busy today, but whats wrong with HTML::Entities ? It does what > we want, and its ready to use. Check it out. It deals with character entities. For encoding that's great. For decoding it's not necessarily what we want -- blanket re-encoding re-fangs the poisoined data. Only re-encoding specified HTML tags (and specific key=value paris for that matter) makes for much, _much_ more safety IMO. For the discussion board example above, only a, img, pre, code, p, font, and super HTML tags (tags, not entities [characters]) will be re-encoded, and for those, only the specified attributes should end up being present again. That way we're > > When you call self->query()->param(), it should return you the string > after it gets filted through HTML::Entities::encode. This will protect > us from everything. When you call self->query()-param() it should either > return you the unfiltered param, or filte it back through > HTML::Entities::decode. Does that make sense? If we just encode the decoded data, then we're right back where we started. If we only encode the 'safe' bits (the list of safe bits being defined by the administrator), then things like script/object/embed shouldn't slip through - nor should onClick() or onMouseOver() or whatever else gets invented down the road... k > > Or, perhaps even better yet, make a decoder wrapper for the query (what > > design pattern is this? delegation?): > > Yes, but lets delegate to HTML::Entities rather than roll our own. HTML > is a PITA and I'd rather let a dedicated module on CPAN grow and mature > than have to do everything ourselves. In the absolute worse case, we > patch it and forward a fix on to the author. > > <snip> > > What do yout think? > > > > Well, its a good idea, but I think its more work than we htink it is to > do it right. Thats why I'm pushing for a module whose sole purpose in > life is doing this sort of thing. That way we use a tool suited for the > job and get on with writing the application server. Thats all. -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Mental <me...@ne...> - 2002-05-23 15:40:20
|
On Thu, 2002-05-23 at 11:23, Kyle R . Burton wrote: > Yup, that's kind of where I was going originaly. > Heh, took me a while to catch up :) > _Great_ idea. Now we just need a way of re-encoding specific tags for > the convinience of our users... > > my $decoder = Org::Bgw::Pas::HTML::EntityDecoder->new( > a => [qw( href name alt )], > img => [qw( src alt height width )], > pre => [qw()], > code => [qw()], > p => [qw()], > font => [qw()], > super => [qw()] > ); > my $discussionMessage = $decoder->decode( $self->query()->param('message') ); > I'm kinda busy today, but whats wrong with HTML::Entities ? It does what we want, and its ready to use. Check it out. I gotta go to the bank then pick up my car. So I wont have much time to hack on this today. > In the above, we also specify a list of allowed attributes -- by default > our entity decoder should strip attributes and values, only allowing them > if they are specified _explicitly_. That way we're protected from onClick() > and similar types of riff-raff. Including stuff that we don't yet know about. > When you call self->query()->param(), it should return you the string after it gets filted through HTML::Entities::encode. This will protect us from everything. When you call self->query()-param() it should either return you the unfiltered param, or filte it back through HTML::Entities::decode. Does that make sense? > Or, perhaps even better yet, make a decoder wrapper for the query (what > design pattern is this? delegation?): > Yes, but lets delegate to HTML::Entities rather than roll our own. HTML is a PITA and I'd rather let a dedicated module on CPAN grow and mature than have to do everything ourselves. In the absolute worse case, we patch it and forward a fix on to the author. <snip> > What do yout think? > Well, its a good idea, but I think its more work than we htink it is to do it right. Thats why I'm pushing for a module whose sole purpose in life is doing this sort of thing. That way we use a tool suited for the job and get on with writing the application server. Thats all. -- Mental (Me...@Ne...) |
From: Kyle R . B. <mo...@vo...> - 2002-05-23 15:24:05
|
> > The point is that we're taking the security standpiont: 'allow everything > > implicitly, deny specific instances explicitly', which will cause us to > > have to run to keep up with every new security hole. 'deny everything > > implicitly, allow specific instances explicitly' has historicly been a > > much more successful secuity approach (look at Unix). > > > > Too true. And this pretty much pushes us to option 1. The real tricky > bit is spotting the html fragments. Its such a hacked up markup language > that its going to be difficult to spot eveyrthing. We might as well just > look for < string > and encode that. Which goes back to your original > idea of simply encoding < > everything that contains those > characters. That should (might not, but should) solve 99.99% of the issues. I hesitate to say that it'll solve 100% of them...but that might just be because I have a hard time beleiving in absolutes. > Oh dude! How bout this: > > We encode everything. But we also include an convenience method to undo > our stuff. Yup, that's kind of where I was going originaly. > Thus, for displaying content on pages, you'd do > $self->query()->param('userinput'); and the browser will get back the > neutered query parameters. This is no problem for the browser, because > it'll render correctly. But we also have a method liek > $self->query()->raw_param('userinput'); that returns the raw, unfiltered > (or at least put-back-the-way-it-was) user input. Page objects that need > it (like to store in a database) would use that. Those objects already > need to to input validation for that sort of hting (or it'll be too big > for the column, or not meet input criteria, or something). Hrm...that's a nice standard, easily integrated way of doing things. Great idea. It fits nicely into the API, doesn't break existing code (unless you count stopping XSS as breaking code ;), and makes a clear and explicit seperation between the normal params and the dangrous ones (param vs raw_parm - naming it raw_param was a good idea dude). > This way, simplistic attacks get diverted, and developers dont need to > reimpliment the same code in every page they write. > > Good idea? Bad idea? Need more tea? _Great_ idea. Now we just need a way of re-encoding specific tags for the convinience of our users... my $decoder = Org::Bgw::Pas::HTML::EntityDecoder->new( a => [qw( href name alt )], img => [qw( src alt height width )], pre => [qw()], code => [qw()], p => [qw()], font => [qw()], super => [qw()] ); my $discussionMessage = $decoder->decode( $self->query()->param('message') ); In the above, we also specify a list of allowed attributes -- by default our entity decoder should strip attributes and values, only allowing them if they are specified _explicitly_. That way we're protected from onClick() and similar types of riff-raff. Including stuff that we don't yet know about. Or, perhaps even better yet, make a decoder wrapper for the query (what design pattern is this? delegation?): my $queryDecoder = Org::Bgw::Pas::Request::EntityDecoder->new( $self->query(), 'values' => { 'a' => [qw( href name alt )], 'img' => [qw( src alt height width )], 'pre' => [qw()], 'code' => [qw()], 'p' => [qw()], 'font' => [qw()], 'super' => [qw()] } ); my $discussionMessage = $queryDecoder->param('message'); The call to EntityDecoder->param is just a wrapper for the real call to $query->param(), which decodes data on it's way out (perhaps even caching results so subsequent calls don't incurr the overhead of decoding). That way we basicly just implement 1 method in the Request::EntityDecoder - param(), and it's easy for people to sub-class it to implement thier own decoders. We could make the standard query object an instance of this proposed Request::EntityDecoder, and make it easy to change by having it in the config file: #pas.request.type=Org::Bgw::Pas::Request pas.request.type=Org::Bgw::Pas::Request::EntityDecoder pas.request.decoder.params= 'values' => { \ 'a' => [qw( href name alt )], \ 'img' => [qw( src alt height width )], \ 'pre' => [qw()], \ 'code' => [qw()], \ 'p' => [qw()], \ 'font' => [qw()], \ 'super' => [qw()] \ } What do yout think? Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Mental <me...@ne...> - 2002-05-23 15:01:57
|
On Thu, 2002-05-23 at 10:49, Kyle R . Burton wrote: > ? Don't like this approach? Still htinking about it. > The point is that we're taking the security standpiont: 'allow everything > implicitly, deny specific instances explicitly', which will cause us to > have to run to keep up with every new security hole. 'deny everything > implicitly, allow specific instances explicitly' has historicly been a > much more successful secuity approach (look at Unix). > Too true. And this pretty much pushes us to option 1. The real tricky bit is spotting the html fragments. Its such a hacked up markup language that its going to be difficult to spot eveyrthing. We might as well just look for < string > and encode that. Which goes back to your original idea of simply encoding < > everything that contains those characters. Oh dude! How bout this: We encode everything. But we also include an convenience method to undo our stuff. Thus, for displaying content on pages, you'd do $self->query()->param('userinput'); and the browser will get back the neutered query parameters. This is no problem for the browser, because it'll render correctly. But we also have a method liek $self->query()->raw_param('userinput'); that returns the raw, unfiltered (or at least put-back-the-way-it-was) user input. Page objects that need it (like to store in a database) would use that. Those objects already need to to input validation for that sort of hting (or it'll be too big for the column, or not meet input criteria, or something). This way, simplistic attacks get diverted, and developers dont need to reimpliment the same code in every page they write. Good idea? Bad idea? Need more tea? -- Mental (Me...@Ne...) |
From: Mental <Me...@Ne...> - 2002-05-23 00:04:46
|
On Wed, May 22, 2002 at 07:11:16PM -0400, Kyle R . Burton wrote: > > Thats good, but you're logging the victem. which is cool, but they're just > > a victem. > > Yeah, but it can [help] tell you who the user was and warn them. If you > were a clueless user, wouldn't you want to know that you might have been > compromised? It might not be easy, but you can use the IP addr to help > track down what happened...granted I agree the victim's IP addr isn't > going to tell you who the attacker is, but it's still useful info. > > You might want to help them...the ip addr is good for that. Worthless. Proxy. Dialup. There's so many issues. For every one user you can track down, there will be 100 more you cant. The time spent will add up quickly. Thats why preventing the attack from working in the first place is so critical. Not everybody has a static ip. Even if you narrowed it down to the company firewall the user was going through, then what? Dear pos...@do..., One of your users might have had his session altered on our website on $DATE. Please let them know. Thank you. This is one of the times the anonymity of the internet is a bad thing. This is also the driving force that motivated me to try to do something about it. I wont know I'm sucessful until more people use it. Maybe we should announce it somewhere.... -- Mental (Me...@Ne...) There was a power outage at a department store yesterday. Twenty people were trapped on the escalators. --Steven Wright GPG public key: http://www.neverlight.com/Mental.asc |
From: Kyle R . B. <mo...@vo...> - 2002-05-22 23:11:33
|
> Thats good, but you're logging the victem. which is cool, but they're just > a victem. Yeah, but it can [help] tell you who the user was and warn them. If you were a clueless user, wouldn't you want to know that you might have been compromised? It might not be easy, but you can use the IP addr to help track down what happened...granted I agree the victim's IP addr isn't going to tell you who the attacker is, but it's still useful info. You might want to help them...the ip addr is good for that. Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kyle R . B. <mo...@vo...> - 2002-05-22 22:42:13
|
> > Yeah, I'll add that to the log statement. One thing I just thought about, if the query param name or query data is extremely long (a distinct possibility), then we should truncate it for logging purposes...but what's agood upper bound for that? Should we just not log the possible XSS string? We don't want malicous code filling up the log files or file systems... What should we do? > I added this function: > > sub _xssAttackLogSummary > { > return "REMOTE_ADDR: $ENV{'REMOTE_ADDR'} : " > . "REMOTE_PORT: $ENV{'REMOTE_PORT'} : " > . "HTTP_REFERER: $ENV{' HTTP_REFERER'} : " > . "HTTP_COOKIE: $ENV{' HTTP_COOKIE'}"; > } > > Which is used in the logging -- is there anything else appropirate that > we should add here? > > In most instances, that data could help you identify the user and where > they came from when the attack occurred. > > Awesome feature. Thanks Jason. > > > Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kyle R . B. <mo...@vo...> - 2002-05-22 22:36:45
|
> I have to admit, it's gives me a warm feeling to see the potential attack > attempt show up in the log file with the remote IP addr attached to it. > > Hrm...we should probably log the HTTP referrer as well - isn't that how > alot of the XSS security holes happen? People click on links on site A, > that points to B and takes advantage of query/post data being echoed back > by site B? > > Yeah, I'll add that to the log statement. I added this function: sub _xssAttackLogSummary { return "REMOTE_ADDR: $ENV{'REMOTE_ADDR'} : " . "REMOTE_PORT: $ENV{'REMOTE_PORT'} : " . "HTTP_REFERER: $ENV{' HTTP_REFERER'} : " . "HTTP_COOKIE: $ENV{' HTTP_COOKIE'}"; } Which is used in the logging -- is there anything else appropirate that we should add here? In most instances, that data could help you identify the user and where they came from when the attack occurred. Awesome feature. Thanks Jason. Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kyle R . B. <mo...@vo...> - 2002-05-22 22:31:11
|
They've been checked in. I updated the Changes file. I have to admit, it's gives me a warm feeling to see the potential attack attempt show up in the log file with the remote IP addr attached to it. Hrm...we should probably log the HTTP referrer as well - isn't that how alot of the XSS security holes happen? People click on links on site A, that points to B and takes advantage of query/post data being echoed back by site B? Yeah, I'll add that to the log statement. You konw, in the Java Servlet model, you _can not_ modify the request's parameters - they're read only. You can modify request attributes, but they're not the inbound data. So you could set up the convention that you scrub the parameters and move them to attributes, but that's only a convention, you're in no way really protected. With Pas, you're protected by the architecture components...that's a good thing. Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |
From: Kyle R . B. <mo...@vo...> - 2002-05-22 22:17:24
|
> > Ok, I'm about to check in a changed version of the function. The changes > > include support for defanging the query parameter names, and it accounts > > for multiple values for a query parameter. It also uses the logging to > > log a warning that includes the remote addr (not completely reliable, but > > better than nothing). > > Hey thanks. Dude, thank you for implementing it in the first place. From here on forward, I'd like to see us discuss new objects before we add them -- do a little bit of group desing and concensus descision making before we leap. I'm not proposing backing anything out at this point, just that we [all] try to take a more democratic approach for enhancements that either change the API, change behavior, or add new classes. Silent or invisible changes (like migration of _gss to makeGetSetMethods) are probably ok - just so long as they actualy are invisible. > I'll see what else I can dig up. Next up is me making the CVS code, my > actual honest to god this is what runs the site code. > > I'll need to go back over Justins ideas about the db stuff before I start, > but I may very well wind up doing 2 iterations of Postgres stuff. First > make it work, then refactor how db stuff works in general. Don't worry about how pretty it is, also don't worry about missing features. As long as it doens't break the codebase, check it in -- you never know what everyone else may be able to contribute to your ideas. Working code is alot easier to comment on than just ideas.... I just tested your code with my changes: http://localhost/pas/diagnostics/dump.psp?foo=%3Cscript%3Efoo%3C/script%3E http://localhost/pas/diagnostics/dump.psp?fo%3Cscript%3Ebar%3C/script%3E=%3Cscript%3Efoo%3C/script%3E And it works like a charm -- the scripting is defanged. Thanks! We need to put this in our changes/news file, package up a new release, and update the website, and tell the world that we can stop XSS. Oh, one mroe thing -- how about we invert the logic for the config setting? Make it on by default. So we'd change: pas.enableRequestInquisitor=1 to: pas.disableRequestInquisitor=1 and invert the logic check (if => unless) in the code. That way it's on by default, and an administrator has to ignore our warnings and best coding practices and turn it off explicitly if they want to. ? Kyle -- ------------------------------------------------------------------------------ Wisdom and Compassion are inseparable. -- Christmas Humphreys mo...@vo... http://www.voicenet.com/~mortis ------------------------------------------------------------------------------ |