|
in reply to Re: Passing a regex from a CGI HTML form
in thread Passing a regex from a CGI HTML form
Thank you for the reply. It's a private page used by me and a co-worker at work to run a football competition every week for work mates. The data is scraped (manual copy 'n' paste) from a newspaper site and as the data now is produced on the fly, it is in a real mess - my code 'as is' now parses this and puts it in the format we require Now, the issue is, every week or so, they change something, and my parser breaks (which can be fixed easily when I am at home!), but I am at work, so need a way to add new subsitutions on the fly otherwise all hell breaks lose at work when the results are late! Basically, it's just a fail safe 'in case' and NO security issues at all raise their heads as it is only me doing the input :) Thanks, Nick |
Re^3: Passing a regex from a CGI HTML form
by AnomalousMonk (Archbishop) on Aug 31, 2016 at 18:11 UTC
|
... NO security issues at all raise their heads as it is only me doing the input ...
"Unfortunately, Dave, that sounds a lot like Famous Last Words." :)
Give a man a fish: <%-{-{-{-<
| [reply]
[d/l] |
|
|
I know what you mean, but it is only me that knows the page address (it's on the Internet, but no way can anybody know the address, let alone guess it) - let alone do the input. Nick
| [reply] |
|
|
Never say never. Security through obscurity is not a way to go through life... things always start out as "it's safe, because it's only me", but then as things expand or others are involved, the gaping security holes are forgotten about and blamo, you're at risk (especially when using eval on user-supplied code).
| [reply]
[d/l] |
|
|
|
|
|
Re^3: Passing a regex from a CGI HTML form
by haukex (Archbishop) on Sep 03, 2016 at 10:32 UTC
|
Hi Linicks,
Doing an eval or s///ee with a value supplied by a user on an HTML form is the equivalent of giving that user shell access to the machine. You keep saying that only you know the address of the machine, but if security by obscurity is your only security, then one day, for example if your page is discovered by a crawler, that'll mean game over for your server. That's why everyone has been saying to be very careful with eval and security by obscurity, and they are right!
To make one more recommendation because I don't think it's been made yet: At least throw some HTTP digest authentication on there along with the SSL.
Hope this helps,
-- Hauke D
| [reply]
[d/l] |
|
|
Hi Hauke D, Thanks for the reply. I have now implimented a bit of 'magic' in the form to only allow the script to be processed if known. As to web crawlers, how can a crawler 'slurp' a page that isn't advertised anywhere? Lastly, something that nobody mentioned here - OK, using 'eval' and the like is equivalent to giving shell access, but surely it will only be as the UID/Group I run apache under? Thanks, Nick
| [reply] |
|
|
Hi Linicks,
OK, using 'eval' and the like is equivalent to giving shell access, but surely it will only be as the UID/Group I run apache under?
Yes, that's correct, and the server process is often run under the nobody user or equivalent for that reason. But do you know for sure that the server has been configured properly security-wise on the *NIX level? And why let someone even get that far? It's kind of like buying a safe but leaving a back window to your house open and hoping nobody notices. The question is why not lock all the windows and doors too?
As to web crawlers, how can a crawler 'slurp' a page that isn't advertised anywhere?
Essentially every public IP address is probed at one point or another, I've got a few machines with public IPs and can attest to that. If you've got an Apache name-based virtual host, then AFAIK it does become more difficult, but then again I was just naming one example. Another example: can you guarantee that every computer you use to access this page is secure?
Continuing the shell analogy: An HTML form + eval without a password is the same as setting up an SSH user with no password, and then hoping that no one happens to probe that particular IP + port + username combination. However unlikely it may be, once they do find it, they have access - so why not just throw a password on there?
Regards,
-- Hauke D
| [reply]
[d/l] |
|
|
|
|
As to web crawlers, how can a crawler 'slurp' a page that isn't advertised anywhere?
Watch your logs. I was astounded to see hackbots start probing my home computer’s webserver, mostly for PHP vulnerabilities, within something like 20 minutes of opening port :80 to the outside.
I’m not trying to pile on. eval can be dangerous but the way you’re setting things up is probably safe for your intended use. If you were a bank or something, no. When I open personal stuff up to the outside I sometimes pseudo-firewall with IP filtering in the app (plack middleware) and always use htaccess with SSL enforced (also easy with middleware).
| [reply]
[d/l] |
|
|
