Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^3: Setting up a web-based perl interpeter

by Your Mother (Archbishop)
on May 27, 2011 at 16:42 UTC ( [id://907018]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Setting up a web-based perl interpeter
in thread Setting up a web-based perl interpeter

Unless any part of the served pages ever, at any time, calls an external URL or visits one from it. Plus IP filtering is a form of authentication and, without reverse look-ups, not a "very secure" one.

  • Comment on Re^3: Setting up a web-based perl interpeter

Replies are listed 'Best First'.
Re^4: Setting up a web-based perl interpeter
by Anonymous Monk on May 27, 2011 at 16:52 UTC
    True, those situations can arise. But remember you still have two forms of verification even if the address is known to web servers. You still have an IP validation which in itself isn't so secure however unless they know what IP you are using it won't do them any good. Or throw the reverse look up on there, too. That won't require the OP to do anything extra when they load the script.

    When visiting other pages it never shows the URL params. It won't pass on that you had to do script.pl?this=that. It'll just show script.pl.

    I'm not saying the script is fort knox worthy but this is more or less secure.

    There are many ways to secure a script without a required sign on verification process. For instance.. make a requirement that a script on the server is run within the past hour or the script won't run. Ie: have another hidden script on the server that timestamps a file that the perl intepreter then reads. If it was last hit over an hour ago the script doesn't execute. It's simple to do and makes the script live only as long as that time frame. And to increase that, add the function script.pl?time=stop to instantly kill access when you're done with it.

    It may seem like a lot of small things but it would absolutely work with what the OP is trying to accomplish.

      I know what you're saying but you're talking probability more than security. Secure should be considered binary. It's secure (against all known issues) or it's not. Anything else is a form of gambling. Maybe you're only betting a couple dollars on good odds so it's not that dangerous but it's still not secure and suggesting it is in a situation where someone is discussing arbitrary code execution from user input is irresponsible even if it's not that risky.

      When visiting other pages it never shows the URL params. It won't pass on that you had to do script.pl?this=that. It'll just show script.pl.

      My access_log records show the parameters passed in a GET request, and the error_log shows the referer (sic) including the parameters if it was a GET request.

      You are using obscurity to secure your script. Once the obscurity is gone, the security goes right with it. Obscurity can be much more difficult to maintain (perhaps approaching "impossible" for anything more complex than a crossover cable) than other methods once $badguy has access to the request path (see previous post in this thread). Maintaining this secure request path is expensive, error prone, and difficult. There are other, more economical solutions available.

      --MidLifeXis

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://907018]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (4)
As of 2024-04-19 06:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found