Should i "use CGI" for a simple HTML file output?

[wardy66]

Hi all

Just a "style" question.

CGI is a standard module and appears to be a bit of an easy way to write HTML.

So, rather than:

print "<h1>Heading</h1>\n";

I can just:

print h1("Heading");[\code]

which seems a little less [i]low-level[/i].

Is this what people normally do? Please note, this script just outputs an HTML file, not a real CGI script.

I see there's also modules like HTML::Table that I might use too ...

Thanks! :)

 

[KevinADC]

Of course it all depends on exactly what you are doing, but using templates has gained in acceptance quite a bit, like HTML::Template or using your own templating system. You could also use CGI to generate your HTML if that seems appropriate to your application. I personally only like to use templates when there are many repetitive pages that can use the same template. But there are really no restrictions, it's all up to you.

 

[TrojanWarBlade]

The big issue that you miss when you consider the CGI module to be "just a little less low level" is that when all your CGI/HTML generation occurs in CGI.pm instead of your own code, you gain the benefits of tried and tested code for parameter processing and security and bug fixes.
If a bug or security hole is discovered in CGI.pm, it'll get fixed and you can download a new version and install it. Then all your code is instantly protected from the latest issues.
If you write your own hand crafted code then you may not even be aware of any issues like this and even if you were, correcting them cuold become a nightmare if you have many script.


Trojan.

 

[1DMF]

Trojan,

How is writing your own HTML code a security risk in PERL.

You're scaring me!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

LOL,
If you're writing CGI then a user could pass anything to you.
You should ALWAYS run -T (taint check mode) which will force you to check ALL data that the user supplies.
Also, you should always "use CGI" for the same kind of reasons. The CGI module has been extensively tested and will be updated when any security issues or bugs become known.

To give you a simple idea of the kind of thing that can cause a problem is where your webpage asks for (say) a username and uses that username to open a file. and display the results.
It's possible for the user to give a name of (say) /etc/passwd for example.
This is a bit of a dumb and unrealistic example but it shows you the kind of thing I'm talking about.
With CGI processing, you're defeding against people making your script do something it was not designed to do simply by supplying unexpected data in "<input>" fields.

Does that make any sense?


Trojan.

 

[1DMF]

how would you do that? make my script misbehave!

I have a form username and password, I use a sub to read Form & URL data and place into a hash.

I then check the specific hash keys and values for expected data, if I don't get a match the script bombs, how do you HACK my script from these form fields?



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

I'm not saying that I could. You are validating the username properly so you should be safe.
But many people write scripts that do not check things properly and therefore are vulnerable.
How do you check the password? Do you check it in a database?
Have you heard of SQL Injection attacks?
If not, google around and read up about them. You might be surprised just how easily your code can be compromised.


Trojan.

 

[1DMF]

I don't want to read up , ignorance is bliss, as if you guys don't give me enough to do after pointing out the flaws in my coding

I've just released Version4 of our companies members area and i'm working till silly o'clock when i get home redesigning my record company site, now i've seen the light again thanks to you guys, i'm using SHTML, SSI, Modules, SQL, Complex Data Structures, Loops, Strict, Warnings, blah blah blah - man it would have cost me a fortune to have paid to learn everyhthing you lot have taught me, infact I probably wouldn't have learnt as much or enjoyed it as much either!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

I'm glad you're impressed.
There is a lot of talent here so it's nice to see that you appreciate that.

I would say though that ignorance is possibly dangerous bliss!


Trojan.

 

[audiopro]

[i]
But many people write scripts that do not check things properly and therefore are vulnerable.
[/i]

I too have been writing code blissfully unaware of the dangers which lurk out there although I do use CGI Params cus you guys told me to.
How does reading data via CGI protect us?

Keith

http://www.studiosoft.co.uk

 

[TrojanWarBlade]

It's a start but your main protection (other than common sense!) is the taint option (-T).
It forces you to test (and hopefully validate) everything that comes from the outside world.


Trojan.

 

[audiopro]

I have been reading up on SQL Injection attacks and it all sounds rather scary.
One of the examples I read warns about using usernames and passwords as parameters in MySQL queries, as dangerous code can be embedded in them, causing a dodgy query to be made on the database. I have in place a few security measures such as checking that the format of the password matches the site generated format and that usernames contain only letters and numbers.
What checks should be made on incomming general data which could contain harmful words in a totally legitimate variable?

Keith

http://www.studiosoft.co.uk

 

[TrojanWarBlade]

The obvious rule is to use regexs or the like to filter incoming data down to the fewest possible alternatives.
For example, if a username can only be 6 capital letters then filter it to only 6 capital letters. That way, no-one can inject SQL code.
Hope that makes sense.


Trojan.

 

[audiopro]

The username and password fields are of fixed format already so are easy to check.
My main concern is a field we use to search the database for certain words. The words DROP, DELETE, SHOW and INSERT would be acceptable search terms for the services we have available.
I already do regex's which match my table names and throw an error if a match is found but is this nenough.

I'm not paranoid - I know they are out to get me!

Keith

http://www.studiosoft.co.uk

 

[1DMF]

shoot, are you telling me that if a Pword is entered

DELETE FROM tablename WHERE 1=1

and i just used this to query the table..

SELECT * FROM tablename WHERE Pword='$pwd'

that the select will execute the command entered in for $pwd.

Surely it will just treat the input as text for matching won't it ?

and not return any records because no pwassword in the DB is equal to 'DELETE FROM tablename WHERE 1=1'


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

It depends on HOW you submit the SQL.
Again, this is another reason for using placeholders. It minimises the chances of injection attacks (but is not a reason to not bother checking the params!).


Trojan.

 

[spyderco]

My scripts are pretty darn secure if I do say so myself (and I do!) and I don't hardcode CGI.

When I first started I used print h1; and such but it's not very time effective. The reason I was told it still exists is because it'll make your code more portable into other computers and operating systems.

I do disagree with this because if you write your own HTML output, it'll be the same on any computer you use it on.

print "<h1>hello world</h1>";

Is much more realistic. Less chance of making a typo and it's a million fold easier to come back to a year from now and pick up where you left off.

Whenever secure information (email address, phone numbers, addresses, payment info) it is important to secure the data. This is actually where the fun in Perl begins is when you work your hardest to see if you can outwit those potential threats out there. Sometimes you do..Sometimes you don't, but you live and learn.

If the member area doesn't contain crucial user data, it's not so much of a worry to protect it. It'd still be nice to practice on it for when you have a script that really neads it.

Oh, last but not least. You better be darn sure any script you write that sends out e-mails is written properly. You don't want people using it to spam others!

 

[TrojanWarBlade]

Spyderco,

Are you suggesting that people should write html directly instead of using the CGI module? And are you suggesting that doing that would be more portable?


Trojan.

 

[KevinADC]

I think the biggest mistake many beginner-ish coders make with password/usernames is they rely totally on the login-screen to not allow entry into a site or part of a site, just like a security door into a building.

I've pointed this out on occasion in other forums, that once a person has gotton past the login screen (the door), they can save any forms to disk and access them without having to login again unless the script continues to check for names/passwords.

Do not depend on a login screen to protect people from getting to your sensitive forms or other content.

 

[TrojanWarBlade]

I agree with your points but you didn't answer my questions.


Trojan.