Hi On Fri, Jan 18, 2008 at 09:49:10PM +0100, [EMAIL PROTECTED] wrote: > In the last couple of weeks I have been reading a lot of security > related literature with a strong emphasis on web related issues. > > It seems to me that a lot of people tend to call themselves "Security > Experts" and they work with security and they write articles and/or > books about the subject. > > But.. is it just me or is there something wrong somewhere!? A LOT of the > examples provided in the material are just so damn stupid that I can't > believe anyone can take them serious. Most certainly, like in every subject, the signal-to-noise ratio is not very good. In my experience, coupling the words "web" and "security expert" is almost certainly going to result in almost 100% noise...
> A lot of the material are using example where a malicious user inserts > some code into the web page which is pointing towards a hostile server. > In order for this thread to be executed the attacker must "hack" the > server (we are not talking about cross-site problems). WTF!? Someone > hacks the server and the document talks about a session fixation attack. > Yea, sure, someone might "hack" a web server in order to insert > malicious code, but I don't really think that's our main problem then, > our main problem would be to take the damn server off-line and start > working out the main problem: How the h... the server got hacked in the > first place. You could "hack" the user the site runs as, but not the whole server. It is often through such small, "insignificant" holes that you can mount an attack, since they were not considered. My (very inexperienced, useless and non-authoritative) view of security includes trusting as few things as possible. Instead of thinking "if X is exploited I have bigger problems" I try to make the rest of the system trust X as little as possible. That can very well be the difference between an exploitable vulnerability and a DOS, for example. Especially important is to understand that you can not know all the possible attack vectors. If you assume the only possible attack on a server is root compromise you are missing quite many. > For example in the "Threat Classification" manual written by different > people from the "Web Application Security Consortium" there is this example: > > <snip> > > Issuing a cookie using an HTTP response header. > > The attacker forces either the target web site, or any other site in the > domain, to issue a session ID cookie. This can be achieved in many ways: > > * Breaking into the web server in the domain (e.g., a poorly maintained > WAP server). > > </snip> This is about damage spreading from one machine in the domain to another one. In the real world you rarely control all the machines in a domain. > I have also found a lot of other examples in other books, Chris > Shiflett's book about PHP security also uses some rather obscure > examples (no offence Chris) in which I tend to think: Dude if that can > happen to someone running a web server he's to stupid to understand what > you are writing and he shouldn't be running a web server in the first place. Unfortunately people who shouldn't be running web servers are running webservers and people who shouldn't program a calculator are programming web applications. That's life... The far-fetched examples do serve one purpose: they teach you to open your eyes. If you just memorize them without changing the way you think and try to avoid those particular mistakes, you have failed to really learn of them. PS. I'm no security expert, and I doubt I will dare to call myself one in a long time. Always use your own brain and take my answers with a large grain of salt. -- Jussi Peltola
