Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
If you have some interesting news or want to throw up a link to discuss it, here's the place. Anything is okay, even shameless vendor launches (since that is often applicable to what we work on). 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: zeno
Date: December 21, 2006 01:09PM

I'm sure this will piss off a few people :)

http://www.cgisecurity.com/2006/12/10

Comments welcome!

- zeno
http://www.cgisecurity.com



Edited 1 time(s). Last edit at 12/21/2006 01:16PM by zeno.

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: rsnake
Date: December 21, 2006 02:06PM

Doesn't piss me off at all. I have never thought it should be up to developers to understand code, because they are inherently lazy and pompous people who think they already know everything. Taking it out of their hands is the right long term solution. In the short term, however, they're screwed.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: jungsonn
Date: December 22, 2006 05:22AM

Interesting stuff.

Well, as i see it: security is a whole process. You could code very secure, but if I get r00t through a very poor chosen password by you, it does mean that you are not secure. the code could be secure., let alone social engineering. 100% tight security is an illusion, it will never happen. I hear people talking about encryption and stuff, about hashing the hashes, quadriple the encryption, having longer keys, and all that nonsense, SSL, and stuff. Thinking that that is going to secure them. Depending on the situation, encryption could even weaken a system. And encryption in the deepest sense is really security through obscurity, passwords are really security through obscurity.

I always write as less code as I can. If i can make the same program with 700 lines less code, it means I can do the same thing with less code. So i'm very pragmatic when coding, but let me guess how many people store the config.php files in the www folder? any reason why you should store it out of the www doc root? yeah, sure what if PHP crashes? It happened once at a client of mine. PHP stopped functioning and all php scripts we're accessible as plain .txt and .html files. all that sort of things, I can go on and on about securing scripts, But there is always a hole somehwere, and most often in the place you would not thought about. What to think about hacking into a datacenter, going inside their routers, sniffing every packet, If i can access a box there which has a few hundred sites on them, i got access to over a few hundred sites instead of 1 which i could gain through the pain of SQL injection, XSS, etc. I have virtual hosting myself. I'm pretty keen on securing my part of the virtual account, but who knows, maybe my provider doesn't give crap about it, and has his root password like: qwerty. then I'm fucked, i could code as much as i want, it would not help me. security is always a tradeoff, no matter the place or the situation, online and offline.



Edited 1 time(s). Last edit at 12/22/2006 05:57AM by jungsonn.

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: kuza55
Date: December 22, 2006 06:06AM

I think the word framework in the title is really rather odd, since personally I would call Java a language rather than a framework, just as I'd call PHP a language, and Cake PHP would be a framework.

Personally I completely agree with this though. Everything we deal with in web apps could really be solved with more restrictive defaults. ASP.NET has got XSS holes destroyed (according to your article - and directory traversal could probably be destroyed in the same way), SQL/LDAP Injection could be prevented if the default way to make SQL queries was bound parameters (the same could be said of system command injection), RFIs will probably be dead soon as people upgrade to new versions of PHP where allow_url_fopen is turned off by default, HTTP Response Splitting is all but dead (I think there were some isolated cache poisoning issues for certain caching programs, but mostly its fixed) in newer versions of PHP anyway.

And the only things that I can think of are CSRF, email header and regex injection, some minor format string stuff, session fixation, file upload attacks, dynamic variables (double dollar vulns), some null byte issues and $_REQUEST variable fixation.

And frankly those are very rare attacks from what I've seen.

But for the large attractive targets we've never had that many obvious exploits (well, except for XSS holes), and we've had to go to extraordinary lengths to disect their applications to play things off against each other.

So while frameworks or good language constructs help, they're not going to help popular websites since they either had security concious programers, or have been through the whole band of easy to find vulns.

But this is really still the developer's fault, not for writing insecure code (everyone makes mistakes or forgets about, or doesn't know something), but for recomending insecure practices to others. When I was learning PHP not a single site mentioned bound parameters, and so I never really got into the habit of using them, and while I learnt fairly soon to escape my user input (because toherwise things wouldn't work sometimes), I never switched to bound parameters. And as long as everyone keeps talking about the old way to do things because it requires less typing or something nothing will change - even if these safer alternatives exist.

.....Hopefully some of that made some kind of sense.....

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: jungsonn
Date: December 22, 2006 06:20AM

True, but to summarize what i really mean, and this goes beyond coding:

1.) A hacker could uncouple the train wagon by wagon by wagon by wagon by wagon.

2.) he could also go to the first wagon, and uncouple it there. If he does so he can drive away and leaving all the wagons behind.

Those wagons are like framworks, libraries, dectectors, security measures, all these wagons attached to the train he wants to steal.

I would go for number 2, which is more clever and faster.

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: zeno
Date: December 22, 2006 12:09PM

The title had to be short and sweet and I wasn't trying to talk about Java or .NET specifically, I just provided examples that people would relate to. I didn't want to use language in the title because one 'can argue' a language means nothing (its syntax), its the compiler, interpretor, VM, and execution/flow of the application (which depends on the former) that ultimately decides many common risks. Deployment issues (including backup files like mentioned above) are a seperate issue. The industry as a whole needs to start thinking about building additional security measures in for common input validation mistakes which would eliminate a large chunk of the issues that we see.

- zeno
http://www.cgisecurity.com/

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: ntp
Date: December 23, 2006 06:52PM

I just thought of a very good point regarding this.

It wasn't until Java and .NET that we were given good strongly-typed languages (Modula-3 does not count because nobody used it). But buffer overflows aren't quite as common in web applications as they were in network listeners.

the C programming language had tons of great frameworks. It had even better teachers and instructional capital. But nobody used them. A person could have been taught correctly and never used the framework, or wrote around the framework.

It wasn't until Java and C# that the problems of C/C++ started to go away. We don't need more/better security frameworks. We need new languages. Languages that disallow making huge mistakes such as improper input validation.

It's going to be awhile before that happens. Something like a paradigm shift.

I don't always feel this negative; and it's just a thought. There are many good/easy ways of dealing with the web application security problems we have today. And security awareness and technology management patterns / software lifecycle has improved tons since the buffer overflow issues between '94 and '99. I expect us to evolve at least twice as fast. Give it another year or two. We'll get there.

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: rsnake
Date: December 24, 2006 12:54PM

That's exactly right. I mean think about it. A huge chunk of what we are talking about is simply verifying that what you are taking in is what you expect, and then making sure that if it isn't what you expect you error out in smart ways. That's literally programming 101. That means that either our teachers are terrible, they aren't being used or the programming languages make that ultra simple task far too complex and arcane.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: zeno
Date: December 25, 2006 06:50PM

That is exactly the point that I was trying to make with this article. I grouped languages, VM's (when applicable), and API's into the term framework.
- zeno
http://www.cgisecurity.com/

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: jungsonn
Date: December 25, 2006 07:09PM

Quote

We don't need more/better security frameworks. We need new languages. Languages that disallow making huge mistakes such as improper input validation.

I think there is nothing wrong with today's languages, It all depend on how you use them properly. Any language has it's own modules and functions which can prevent such issues they can prevent alot, but not everything. it really boils down to proper coding. i think there is also a difference between 'hard programmers' like the C types, and 'soft-web programmers' which utilize ASP, PHP. the danger in these web languages is that it's build by the 'hard programmers' to make it more user friendly for the 'soft-web programmers' and with user friendliness comes security risks, M$ products are the best example of this. So you can use PHP without any fear, if you just build your own functions and classes or 'framework' around it to make up for the initial user friendliness. IMHO it requires only proper coding skills.

Options: ReplyQuote
Re: CGISecurity.com - The lack of security enabled frameworks is why we're vulnerable
Posted by: maluc
Date: December 25, 2006 07:47PM

i think the idea being, that you shouldn't have to extend the language in order to use it properly. Just like all the logic in the electronics hardware world can be constructed solely from AND, OR, and NOT gates.. but many special purpose chips can save you thousands of those individual gates.

In an ideal language, there should be no need to build your own framework with the language just to make it useable in a secure manner. When everyone needs the same security functions, there should be functions to do just that. When everyone needs protections against directory traversals and remote inclusions - there should be security checks that prevent exactly that. And those should be opt-out, not opt-in (i.e. they default to being protected)

I complete agree that we should baby the developers, and that languages should be there to make it easy to build a secure useful site - not just make it easy to build templates that make it easy to build a secure useful site. That's a half-asked job. =.=

And yes, ASP is definitely ahead of the game with it's filtering of GET strings containing < and > .. PHP feels like a middle schooler's attempt at providing a secure language - and don't even get me started on much of their function-naming scheme..

But alas, it's easy to critique from the sidelines. :/

-maluc

Options: ReplyQuote


Sorry, only registered users may post in this forum.