Slashdot Mirror

I understand where you're coming from and I agree with you on some points, such as not deploying a full blown system that includes a dozen features you don't want or use, that's just part of the lockdown of an application. But I see that as making the right choice of 'product' rather than a 'build vs buy' scenario (even if it's free).

A problem I see in my Organisation is the perception that by building a new application from scratch, we can avoid all the bugs that were in the previous 'similar' application. What they don't appreciate is that 1.0 applications always have bugs in them, both security holes and feature bugs.

Being out in the wild and being used is what hardens applications. Sure they had a lot of bugs over their lifetime, but they are known bugs. They are fixed bugs. At worst they are bugs that someone will fix.

Take a look at The OWASP Guide if you want to get an idea of what you need to cover if you intend to build it yourself and mitigate all potential security holes. The table of contents alone is six pages long.

Black Hats (as distinct from AssHats ;-) aren't necessarily going to conform to your sense of security. I don't mean this as inflamatory, but people who aren't security experts don't have a clue about the kinds of things attackers can hone in on. If someone wants to crack your homegrown site there is a slew of things they can try that your typical web developers don't consider.

If one of these 1000 crackers finds a security hole in one of these open source applications, the majority of the time one of the 10,000 hackers fixes the problem within a day or so. It is only the people that don't keep their patches up to date that are vulnerable.

The question is, can you meet that kind of pace on your own application? Your argument has its place, but personally I would never try this. I would find an open source application that most closely matches my needs, to avoid having all the extra features I don't need, and then contribute whenever any security holes are identified. At worst my changes would be peer reviewed. At best someone who knows a hell of a lot more about it can fix it better than me.

This can be useful for you.

Why is this being labeled as something new? I remember this being a problem back in 1997 when I was still working as a webmaster.

Whoever posted this as a "new" item, is behind the times.

OWASP covers it!

Lets not rehash old things!

Also check out The Open Web Application Security Project.

Check out OWASP.

Check out WebScarab, which is available from the Open Web Application Security Project.

The feature you are interested in is:

• Interception Proxy - captures traffic between the browser and the web server and alllows the user to modify HTTP on the fly.

What are some good resources for a web developer to read so that they know how to design secure sites that use RDBMS as a backend?

OWASP is a good start.

Chris from Port80 here.

I was misquoted or rather never asked directly about the subject in the theage.com.au article, so here's what I have to say about IIS security:

http://www.owasp.org/columns/jlima/joelima1

There is work to be done, but IIS is moving in the right direction.

Enjoy the tryptophan effects,
Chris @ Port80

The Open Web Application Security Project have a guide to help those who want to improve the security of their web applications. I've had a skim and it looks pretty good. They claim two million downloads, so other people must think so too. :-)

If you're feeling lazy, you could do worse than reading their list of the top ten web application vulnerabilities.

The Open Web Application Security Project have a guide to help those who want to improve the security of their web applications. I've had a skim and it looks pretty good. They claim two million downloads, so other people must think so too. :-)

If you're feeling lazy, you could do worse than reading their list of the top ten web application vulnerabilities.

The Open Web Application Security Project have a guide to help those who want to improve the security of their web applications. I've had a skim and it looks pretty good. They claim two million downloads, so other people must think so too. :-)

If you're feeling lazy, you could do worse than reading their list of the top ten web application vulnerabilities.

This means that too many people are putting blind faith in php.

It is php which is getting hacked not Linux.

More people should read this

• faster
• more extensible
• easier to extend and to store

Hmmmm.....

I suppose I'll have to throw myself on my own sword.

After digging through the "whisper" entries, it looks as if that is ALL it is... a repository for scripts.

My apologies. I did read the overview, but it doesn't coincide with the actual database.

This is disturbing.

1. Only allow those ports that are absolutely necessary - i.e. HTTP, FTP, SMTP,...
2. Review log files daily. Make it part of your religion. Log files. Review. Daily.
3. Err on the side of being too restrictive.
4. Review log files daily. Make it part of your religion. Log files. Review. Daily.
5. Absolutely keep up to date with your virus signatures and patches for your workstations and servers.
6. Review log files daily. Make it part of your religion. Log files. Review. Daily.
7. Find a few quality security web sites (securityfocus.com, cert and others - check out DMOZ for a nice list of links...) and put them on your daily visit list. Make sure to go to several sites daily and use them to triangulate on what's relevant and important.
8. Review log files daily. Make it part of your religion. Log files. Review. Daily.
9. Visit the IT Security Cookbook and enjoy!!!
10. Review log files daily. Make it part of your religion. Log files. Review. Daily.
11. If you're running a web server on your network, check out the open web application security project. The OWASP Top 10 is a great tool to get you to think about how your web sites can be made more secure
12. Review log files daily. Make it part of your religion. Log files. Review. Daily.
13. Know that you're not ever going to secure everything 100% , but if you make security one of your daily duties and take a proactive approach to security instead of a reactive approach, you'll do better than 99% of the networks out there. Just be diligent, use common sense and stay on top of patches/updates and you'll be fine.
14. Review log files daily. Make it part of your religion. Log files. Review. Daily.

"Apache Security" is probably easy to get the latest information on. Probably for free, and without having to cut down trees.

For example, assuming you have the latest patched apache, the left-over security issues that are CGI/web app/scripting related fall under the web applications category of security.

In this case, have a look at some of the guidlines over at The Open Web Application Security Project (OWASP) .

Way better than paying too much for a book that wastes paper, and will likely be out of date in no time.

--noodles

The webapp side of the security equation is often sadly neglected by people focusing on the network and host levels of the system. (Which, don't get me wrong, are very important in their own rights.) It's nice to see a book that addresses "programmer-level" holes as well as "administrator-level" holes.

A very good site for (free) information on this area is http://www.owasp.org/. OWASP seems to mainly focus on webapp level security, which is ok given the wealth of informative resources out there for the host and network layer. (OWASP = Open Web Application Security Project)

www.cgisecurity.com
www.cgisecurity.com/lib
www.owasp.org

www.cgisecurity.com
www.owasp.org

www.cgisecurity.com/lib
www.owasp.org

www.cgisecurity.com
www.owasp.org

These are good sites with documentation on web security threats along with prevention and detection.

Geez, is that site a piss-poor ripoff of Ximian.com or wot?

Does anyone know of good references that cover the security of web applications from the ground up?

Yes, try the Open Web Application Security Project. They released a very informative paper on building secure webapps, and it's free.

(I'm not affiliated with them in any way)

www.cgisecurity.com
www.owasp.org
www.sqlsecurity.com