|
Managers can't see security
by perrin (Chancellor) on Jun 22, 2002 at 19:34 UTC
|
The main reason for this kind of thing is simple: the people setting the priorities and development schedules at most web sites don't even know what security is. They think security is a checkmark on an application server feature list, not an ongoing struggle requiring diligence from all programmers.
In my experience, when it comes to QA there will be 50 bug reports about that broken spacer GIF you forgot to copy over to the web server but zero mention of things like session hijacking, cross-site scripting, etc. The only exception to this was when I worked at a site that had been attacked before, and people took it seriously enough to hire an outside security consultant for an audit when a new system went on-line.
The other problem, of course, is programmers who don't know or don't care about security. There are lots of people employed building web sites who have a very rudimentary knowledge of what they're doing, and this is true on any of the popular development platforms. I often talk to Java programmers who don't actually understand the HTTP model or even the basics of how forms work. They've been working with toolkits that abstract it all for them.
Ultimately, I suspect most companies will not be secure until after they have been attacked. The majority of web sites out there are ripe for exploits to anyone who actually cares to break them. Of course a single PC on a good link could take down about 99% of them just by running http_load on the right URL... | [reply] |
|
|
The main reason for this kind of thing is simple: the people setting the priorities and development schedules at most web sites don't even know what security is.
guess what ? i've been asked to remove all those "useless security checking stuff" because it was slowing the site down !! i couldn't believe it, but i had to remove everything !! talk about incompetent managers ....
| [reply] |
Re: 標eb Security
by Ryszard (Priest) on Jun 22, 2002 at 18:56 UTC
|
I went on a course one time. It classified people into four general categories:
- Unconsciously Incompetent
- Consciously Incompetent
- Unconsciously Competent
- Consciously Competent.
It strikes me that the original programmer may have been point 1. However the new programmer after instruction from an experienced programmer may be point 2 and heading toward point 4.
What is interesting to me, is that if a website is a very high profile website then the management around the webiste may be in the point 1 mark also.
I 1st had to learn perl in order to build a public website that would be high profile within $MY_ISP. Before building the website, I consulted unix admin on the aspects of the server security, and did quite a bit of research on the aspects of building a secure website.
I guess this is interesting to me because i dont understand why people dont do some research into areas that a) they may be novice in and b) there is bound to be lots of information out there on said topic.
This is espeically "interesting" if there is a potential for serious consequences.
Not too much of a point in the rambling, save that I personally dont understand why people go into projects where the element of risk is high (due to experience and environment) unprepared.
Its just not rocket science to have a google and its inexcusable not to. | [reply] |
|
|
What is interesting to me, is that if a website is a very high profile website then the management around the webiste may be in the point 1 mark also.
Most management is in the first category. There's a reason for that -- their job is a nebulous one, one that's hard to do right and harder to estimate the quality of from the outside.
I'm not apologizing for bad management; it's repugnant that an important job (oversight and organizational design) is so often done by wretched social whores. My point is that the job has high complexity and less supervision, and is therefore likely to be a place that incompetents unconsciously set out to end up.
I guess this is interesting to me because i dont understand why people dont do some research into areas that a) they may be novice in and b) there is bound to be lots of information out there on said topic.
People don't do research because it's hard. There are a class of people who don't do hard things. They don't like hard things because doing hard things invites failure, and failure scares them. Those people push to be managers for the bad reason: Low accountability, easy blame possibilities, high income, etc.
-----------------------
You are what you think.
| [reply] |
|
|
Recently, a friend of mine told me about the same classification regarding the process of learning any skill, but it was ordered slightly differently. It's a really concise and non-abstract way of encapsulating the learning process, which is helpful when people just don't "get" things like Zen philosophy. A few annotations might clarify:
- Unconciously Incompetent - Ignorant of your own lack of ability, unaware of any structure or limitations, and have no idea of the big picture. May perform by imitation and without understanding the rationale.
- Conciously Incompetent - Realization of structure, scope, and limitations. Have an idea as to how to things work, but perhaps an incomplete one, and are still learning how to operate effectively.
- Conciously Competent - Have "seen the elephant", understand how things work, and have enough experience to not get into trouble. However, a certain amount of deliberate concentration is required in order to perform. There is a little hesitation and uncertainty.
- Unconciously Competent - Performing no longer requires active effort, as practice has made this habitual and innate.
In a nutshell, you start out having no idea you know nothing, and end up with no idea how much you know.
| [reply] |
|
|
I went on a course one time. It classified people into four general categories:
Unconsciously Incompetent ;
Consciously Incompetent ;
Unconsciously Competent ;
Consciously Competent.
Was the course a book called "Mega Memory" by Kevin Trudeau?
- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.
| [reply] |
|
|
| [reply] |
|
|
I suppose these categorizations could be coined "2-bit competencies".
| [reply] |
紐e: 標eb Security
by merlyn (Sage) on Jun 23, 2002 at 13:52 UTC
|
From what I understand, there was temporarily a note here from a fellow monk about how I had doubled the damage by revealing specifics.
Please let me assure you that the code snippet I posted
by deliberate action:
- Did not mention the name of the client
- Changed the name of the parameter
- Changed the eval-ish code
Yes, a correlation between the timing of my rant and
my public schedule does indeed reveal that this is a $VERY_LARGE_COMPANY in Silicon Valley. I'll grant that
as a leak. But the web search suggested to me in the
message box revealed only a handful of companies, none
of which is $VERY_LARGE_COMPANY.
Please give me a little credit here. I'm not willing to
compromise my customer's security (even if they've
already done it themselves). I'm just pointing out the
sad state of web security in the world, and being afraid
for my own transactions as I continue to shop and bank
and share information on-line. And hoping maybe I can
stir some of you up to take on security with a bit more vigor, or know when to call in the experts if you don't
see why having eval and fatalsToBrowser were both compoundingly bad news there.
-- Randal L. Schwartz, Perl hacker | [reply] |
Re: ?Web Security
by JSchmitz (Canon) on Jun 22, 2002 at 18:11 UTC
|
Actually there is a lot of this going on right now at all companies. There have been so many cutbacks and layoffs that
many IT groups are without good help because the expensive folks that knew what they were doing got laid off. I know of many stories like this. For instance there is a medium size company here in Houston that now has windows help desk people maintaining $250,000 worth of Sun production servers and all they got was one Sun System admin 1 class. In the case above instead of hiring a competent programmer some manager looks better on paper by telling the girl that makes
a lousy 35k a year to "learn perl". The good news is that capitalism is booms and busts and eventually things will turn around and companies will start spending again.
Cheers
JSchmitz
| [reply] |
|
|
I started doing sensitive web coding maybe 3 years ago.
At the time I was getting paid 21.5k as a graphic designer (i was desperate). This was a small company
The owner was a salesman. Talked a lot of sh1+ to clients. .. things like 'and javascript is a technology we are ready to create for you- we have mastered a specific way that only we use to place javascript on your website for your... 'and 'we have understood how google works and we have figured out how we can get you a top spot in google..' you get the idea. It was excruciating to hear. You had to excuse yourself mid-meeting.
I had not done any real web coding- but the company had some intereting opportunities.- and .. hiring a real coder was out of the question.. you might as well have suggested 'why don't we blow up our cars in the parking lot?'
So.. I took to doing some stuff. Latern on it got to bigger stuff... and then people appeared with little budgets and serious needs.. and the company was happy to provide.
The boss harassed to no end - saying if a project was not complete soon - it would be given to some macromedia flash designer.
I tried to explain . .. look.. this is what can go wrong.. I'm debugging because it's a little harder to do this the right way. This really happens out there.. no.. seriously.. is it working? yes.. can we make it live? oh god no.. it's just for testing. - things would chill out for a bit but then.. the pressure as if nothing had been discussed.
Where is it? are you done? Why does it have to be perfect? they are not paying for perfect! we don't want perfect! what's taking so long, it should be a 5 hour project! --- and you try not to lose it and say 'we're taking online payments here from people, we are handling financial data, this is not a 5 hour project- we are doing this from scratch - why did you quote for 6 hours before you let me see the scope of the project?'
I almost lost my job and certainly lost my reputation - and any kind of references - working at that kind of place. There was tremendous pressure to do a quick dirty job on some potentially dangerous stuff.
| [reply] |
Re: 標eb Security
by Chady (Priest) on Jun 22, 2002 at 18:22 UTC
|
Well, some people do really get clueless sometimes; I was delighted when I first implemented a search box on my site, it wasn't until very recently that I discovered a huge flaw in it. Here's what I've been using as code:
my $node = param('node');
if ($node) {
my $ref = chady::db::runSQL("SELECT * FROM nodes WHERE title REGEXP \"
+$node\" OR contents REGEXP \"$node\" ");
...
..
This was a case of production code that went published without review... the more scarry is that some people test and review, are aware of what they are doing, and still do it.
He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.
Chady | http://chady.net/ | [reply]
[d/l] |
|
|
What were you afraid it was going to do? Perhaps this?
$node= '"; delete from nodes; ...';
Go ahead and try it (with something less dangerous). It doesn't work for me as I can't put multiple statements in a single DBI prepare().
I'm not defending code like that, I'm just pointing out something that I've always been told was a horrid security risk ("They could do anything they wanted to your data!") that isn't as bad (AFAICT) as lots of people are making it out to be.
Sure, they could probably launch a denial of service attack by making your SELECT extremely complicated if they could guess some of the structure of your database. (:
- tye (but my friends call me "Tye")
| [reply]
[d/l] |
|
|
I in fact was afraid from this delete you're talking about.. and I am using a DBI prepare in the runSQL() sub, it broke when I added a double quote in the query, so I didn't try the delete and assumed it might pass.
I later removed the \Ws from it all.
Thanx for pointing this out.
He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.
Chady | http://chady.net/
| [reply]
[d/l]
[select] |
Re: 標eb Security
by samtregar (Abbot) on Jun 22, 2002 at 19:36 UTC
|
Hhaha, that's a good one. Here's one I found recently that you might like:
foreach my $name ($query->param()) {
$ENV{$name} = $query->param($name);
}
Very nice, eh? Add that to the fact that the rest of the application uses environment variables for configuration and security and you've got a gaping security hole.
I had to spend at least a half an hour explaining why this wasn't such a good idea in an application that takes credit card data. The worst thing is, the guy that wrote it is generally a good programmer. He'd just gotten into a "not my problem" mindset. Someone asked him to make all CGI params available as environment variables and he just did it!
-sam
| [reply]
[d/l] |
Re: 標eb Security
by Marza (Vicar) on Jun 22, 2002 at 20:52 UTC
|
I am not surprised. You already know that security is viewed as an expense rather then a benefit by many managers.
Even if they are "advanced" in their thinking and actually have a security person, they usually don't allow that person to do security work all the time. In another lifetime I was assinged to Internetworking Security for $VERY_LARGE_INSTITUTION; I did get to do some fun stuff and actually tracked a hacker once, but most of the time we did monkey work.
Also don't forget there is my FAVORITE phrase of all:
Put it in now, we will fix it later!
Now what surprises me is that you were shown source. A few companies I worked for would terminate you for that.
| [reply] |
Re: (blackjudas) Web Security
by blackjudas (Pilgrim) on Jun 23, 2002 at 01:22 UTC
|
I work at a mid-sized company that solely depends on income generated by the website(s) it owns. I will add that it does well and wasn't ever really affected by the market fallout.
The company is frugal when it comes to hiring well paid programmers and admins and therefore suffers by not being on the bleeding-edge when it comes to security. I cannot condone these actions but I can certainly understand them. Computers are such commodities these days, that the overall view taken is; we have many replicated backup units that when one gets hacked/rootkitted/fails we pick up one of these units and cart it to the server location.
Very little time is spent hardening the infrastructure, mainly because it was originally built so haphazardly that it would be quite a large undertaking to make it all as secure as possible.
My main focus at this point is creating a large intranet--based webapp, and it is full of security vulnerabilities, I think this is due partly to my own apathy and the pressure to complete the tasks assigned, though rarely I do have extra time by the deadlines and do some security testing. I can certainly understand why an external param run through an eval is a very dangerous prospect. But my apathy stems from the perspective that all systems exist because my company would rather shell out a few extra grand is setting up replicated slaves rather than spending the tens of thousands of dollars (even hundreds) to harden the complete system.
These days all serious companies are trying to make a good go of it and cutting costs as much as possible. In my case this is how the security issue has been dealt with.
On the other hand, when working on my own projects, I make sure they are secure as possible. I don't think there's anything wrong with this approach when your superiors explicitly frown on time spent on security checks/fixes.
I can only sympathize with everyone who sees this as a problem plaguing many companies. It can only get better. When you're a lone ranger, its hard to take on all the bad guys yourself.
BlackJudas | [reply] |
Re: 標eb Security
by Anonymous Monk on Jun 22, 2002 at 17:51 UTC
|
And don't you just know in your gut that the inevitable failures will be blamed on Perl being an unreadable and unmaintainable language? | [reply] |
Re: 標eb Security
by gumby (Scribe) on Jun 22, 2002 at 17:57 UTC
|
The old saying, 'a little knowledge is a dangerous thing', certainly applies here. I blame $VERY_LARGE_COMPANY for their lack of foresight and their desire to use cutbacks to 'earn' them some more filty lucre. | [reply] |
|
|
While I agree that the company should receive a large share of the blame, we should examine why they place so little value on increased security.
Security is a tradeoff, it costs money. In this case the improved security would obviously have been worth the extra developer time required to fix the vulnerability. Many other cases aren't quite so clear and the limited incentives for companies to improve the security of their products are readily apparent. More on this is available at OT: Software & Liability.
| [reply] |
Re: *Web Security
by Juerd (Abbot) on Jun 23, 2002 at 10:14 UTC
|
Is there really that lack of clues out there? I don't know whether to be more scared or saddened.
Unfortunately, yes there is. Code like this, and worse, is used everywhere. And it's often very easy to find, even without the code. There are a lot of domain name providers that have whois lookup scripts to check if a certain domain is available. Many of those use qx// with raw, unparsed (and apparently never tainted) user input. Strangely, the domain perl.com; echo 'No match for "PERL.COM".' often is available.
Size of the company seems not to matter. Small and large companies both have incompetent coders. I am saddened, but a bit scared too. Maybe Perl should be harder, to avoid clueless people from coding without reading documentation?
- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.
| [reply]
[d/l] |
|
|
How about making Perl6 autoenable taint in somewhat the same way it will autoenable warnings for scripts? :) If people's scripts die because they're doing something insecure, and then said people go ahead and circumvent or disable taints, they really won't have any excuses.
Update: If it wasn't obvious: this post was somewhat tongue-in-cheek. :) Maybe more smilies would help? ;)
Makeshifts last the longest.
| [reply] |
|
|
Well, not all Perl scripts/programs are run as CGI applications. Almost none of mine are. Where I work, almost all scripts are run from the command-line or some batch system, not from the Web. And I'll wager Perl still has more non-Web applications than Web applications. (No, I have no data to back this statement, except my distorted viewpoint. But I'm claiming Perl is general-purpose, while others claim it's special-purpose; I'd say the burden of proof is on Them.)
How's a poor perl6 interpreter to know if it should "autoenable taint" for all my programs? It cannot miraculously guess it's running as a CGI program, because that would force perl6 to know about one particular (if common) setup. Not only would that leave many holes, but these holes would also be more dangerous -- due to the illusion of security generated.
Should perl6 run in taint mode for all programs, except if explicitly disabled? This would mean Perl becomes a language which doesn't trust any input. It means I have to flag a whole class of scripts with "no, it's not a CGI script". This is wholly unlike warnings and strict: whereas use warnings and use strict are universally good ideas (except for a few places where they're not so hot), taint is useful only for programs with input that is less trusted than their execute permission bits.
I don't want to have to begin every Perl6 program of mine with
#!/usr/local/bin/perl6
no taint; # Don't pretend I don't know how
# to run a program
no CGI; # Don't parse CGI parameters
no Application::Web; # Don't overload open to open URLs
no GUI::Tk; # Don't do "new Tk::MainWindow"
no GUI::Any; # Don't wrap my script in an event
# loop.
no DBI; # Don't automatically connect to
# a database
no Pod::Any; # Don't print a blank line before
# and after every line beginning "="
no HTML; # Don't switch regexp syntax
no Net; # Don't set $|=1
#use strict; # Unneeded in Perl6! Yippee!
#use warnings; # - ditto -
Each of these hypothetical defaults I switch off would make excellent sense... for a particular family of applications.
I want a general-purpose programming language. Perl's taint mechanism is an intriguing addition to the datatype mechanism. But it's certainly not always needed.
| [reply]
[d/l]
[select] |
|
|
Re: Web Security
by Aristotle (Chancellor) on Jun 23, 2002 at 02:15 UTC
|
A large issue here is that companies that get what they deserve will try and keep the lid on the entire debacle if at all possible. The result is apathetic managers who think security hazards only exist in the minds of the technophiliac loonies they don't get along with anyway. If they happen to be feeling generous they will, as someone put it, maybe make security an item on the checklist.
One can see why the Java security model is so popular; when the language keeps your leash so short you can hardly do anything wrong (or anything period), clueless newbies (read: utterly uneducated people who might even have been ushered into the job; I'm not putting negative connotations in the term here) will not produce security holes the quality of merlyn's demonstration. Of course they'll still fail to notice possible vulnerabilities for SQL injection, cross-site scripting and other subtleties. (Which really aren't that subtle anymore.) But it looks good on paper and gives the manager who has no idea what security is about the satisfaction that he chose the "safe" technology.
There's a hoarde of rude awakenings waiting to be unleashed..
Makeshifts last the longest.
| [reply] |
Re: Web Security
by crazyinsomniac (Prior) on Jun 23, 2002 at 05:25 UTC
|
Yes, there really is a lack of clues out there, especially since nobody is looking for clues to begin with.
You should be both scared and saddened.
This student of yours, didn't bother to slap on a -T on the code she was trying to decipher, so you've got to wonder how much of this is your fault? (who knows, the person who originally wrote this was probably one of your students, and you've got to wonder if she was truly a bad student).
You have to wonder why isn't security the first concern being thought to people...
| [reply] |
Re: 標eb Security
by digiryde (Pilgrim) on Jun 23, 2002 at 22:05 UTC
|
Several places I have worked for scoffed at security, or any other need not immediately visible to management. Many times I have written a requirements document for code based on the requirements document I was given that included performance and security elements that would have added between 2 and ten percent to the project and saved on the need for several servers(admin time and server cost) or would have closed up several security holes (priceless?) only to have the issues scratched from the immediate to-do list and added to the post-installation list. In most cases the performance items were driven back to us within a week of install (black eye) by which time we had those issues dealt with and were ready for more testing for a fast install.
We could have waited a week and installed without issue (smaller black eye), but our immediate management wanted to impress upper management by holding to their insane development time frames. We were almost never asked to do anything security related once the product was in.
The rule I have learned is if they can not see it, they do not care. Typical clueless mindset. We don't need a firesystem until we have a fire. Then its too late.
| [reply] |
|
|
I've been in that awful position more than once, too. The worst of it for me was knowing that I personally din't at the time understand enough about Perl and web security to write code I was tasked with in a resonably safe manner, but not being given the time needed to research and learn or some assistance in finding and closing glaring security holes when I would loudly and clearly proclaim my own ignorance in the area to the bosses.
We were lucky. So far as I know, none of my security ignorance was exploited in the time between putting potentially dangerous code into production and getting one of my co-workers to sneak a break from his own insane time-frame to double check me.
Now that Perl has become more avocation than vocation for me, I've taken the time to close many of those gaps in my knowledge. ;)
-rattus
| [reply] |
Re: 標eb Security
by sboss (Initiate) on Jun 24, 2002 at 18:49 UTC
|
<rambling>
Working as a consultant I see alot of companies doing the same thing. Someone will write some code (pick any language) and put it into production, including mission critical & customer facing production enviroments when the code should never be run in a lab let alone where it is running. Too many webmasters/web developers/etc that generate this code do no error checking at all. I have gone into production sites, entering "scott rules" for every field that had a text box where it was expecting either text (e.g. names, locations), numbers (e.g. phone number, ip numbers, device numbers), text boxes (large input boxes), etc... breaking the interface since it was expecting 1.2.3.4 syntax and I entered "scott rules". After I showed them a simple little code to check to make sure the inputed values are at least in the correct format (e.g. 6.7.8.8 for an IP address), at least their code was a little more stable. But with the cut backs/recession I have seen more and more people inherit code that they do not know anything about the language nor how/why it was written the way it was.
</rambling>
Randal, be very very afraid! It is much worse than you think.
Scott | [reply] |
Reap me please: 標eb Security
by cLive ;-) (Prior) on Jun 23, 2002 at 00:50 UTC
|
Nodereaper - do your business please :)
Post removed after request about security issue it pointed out...
cLive ;-)
| [reply] |
|
|
It may be a crappy script, but until now, that code was in house.
Congratulations, you have successfully missed the point.
You have to wonder why isn't security the first concern being thought to people...
| [reply] |
(zdog) Re: Web Security
by zdog (Priest) on Jun 22, 2002 at 18:15 UTC
|
In the chatterbox, you said, "Oh cool, the vote bots are at it again." I went to check out the post and yes, I downvoted it, too. Why? Because I didn't think it was that great of a post. Granted, you presented a couple of possible security problems that people may want to look out for when they are coding. But did you provide any solutions? No. Instead, you directed your focus away from Perl and talked mostly about the fact that some people write bad code. That's not really a big revelation. And you just had to go further and mock the author. Sometimes even the best of them deserve -- votes and you shouldn't be so quick to assume that votebots are to blame.
Also, I don't think that you have a right to complain about votebots. This post, with seemingly very little quality content, gets up to +5 rep with about 20 minutes. And that's after a couple of downvotes. And that's on a weekend! Which is usually pretty slow.
Zenon Zabinski | zdog | zdog@perlmonk.org
| [reply] |
|
|
zdog: I have to disagree with your assessment on this one. Different people have different styles of communication and learning and merlyn's style is simply one of many. In this case, his title was "Web Security" and here's what I consider to be the truly relevant paragraph:
In other words, not only was unchecked data from a form field (presumably from a pop-up menu or radio button) being used directly in an eval, but quite helpfully, the syntax errors were being sent back to the browser to help you refine your breakin! (And I looked hard for some sort of screening or vetting of the $p_type value, and there was none.)
In short, merlyn presented some poor Perl code and explained to us exactly why it's a problem. That seems, in my mind, to be a reasonable meditation. Of course, he didn't go step by step through various ways we might exploit this, but there's a certain level of minimum knowledge assumed on the part of the reader. Myself, I like to assume little on the part of the reader so I tend to explain things more in depth (like now), whereas merlyn appears to assume a more knowledgeable audience. Thus, he is often accused of being arrogant or rude and I'm accused of pandering. No matter how one approaches things, some people will be put off :)
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
| [reply] |
|
|
merlyn says:
Is there really that lack of clues out there? I don't know whether to be more scared or saddened.
Ovid says:
there's a certain level of minimum knowledge assumed on the part of the reader.
Anyone see where I'm going with this?
The people merlyn is criticizing for bad security practices aren't going to be helped much by this post. These posts always remind me of the "Perl is Good, Praise Perl" posts that come up on this site. They're preaching to the converted. If you want to help solve the problem, you're going to have to explain things in terms those who you're criticizing can understand.
That said, merlyn's post is not without some value and I don't feel it calls for a downvote, I might even upvote it if he took that dot out of the title ;-).
| [reply] |
|
|
|
|
from dictionary.com:
meditation \Med`i*ta"tion\, n. [OE. meditacioun, F. m['e]ditation, fr. L. meditatio.] 1. The act of meditating; close or continued thought; the turning or revolving of a subject in the mind; serious contemplation; reflection; musing.
The purpose of a meditation isn't to give you the answers rather to inspire you to contemplate the topic.
The less said by every-one about voting and experience the better IMO.
--
my $chainsaw = 'Perl';
| [reply] |
