[Gaelan]

There's an important point I haven't seen discussed yet: I don't believe it's possible to write secure web apps without a templating engine with safe-by-default XSS handling (i.e. interpolated text is sanitized, unless explicitly marked as trusted HTML somehow), which implies some amount of a web framework or at least a web-specific library.

[ozim]

I think important point is distinction between:

a) static documents - basically HTML+CSS and no scripts on the back-end

There is not much to discuss here a lot of stuff could be just that but people don't want to write blog posts directly in html :) We have static site generators that are doing great so it seems to be working well.

b) dynamic documents - you get data from DB based on query, like list of phone numbers in Texas and want to find specific city

Static page generators would not be that useful if one wants to reflect changes from db. Queries are also nicer in db than having insane long list on page with CTRL-F. I would say a CGI only thing would work great for such use case. You probably want to thing about SQL injections but as it is browse only then might not be an issue.

c) web applications - here people want all bells and whistles

Security is important as you probably need authentication and preventing XSS is quite important here. I would never build web application with only CGI - security headers are not that hard to add. But authentication and authorization + XSS prevention is really hard. Then you have lots of requests that send/filter data. You can have problems with SQL injection as you have to store some users and their passwords and their data, framework+orm helps preventing a lot of troubles. One probably should not use a framework for making his blog/static-page. Unfortunately nowadays most people build web apps.

This is what rubs me with posts about "you don't need X framework, it all should be static documents", well yes you don't need big framework if you build personal website. You probably need one if you build a web app. Downside is we have HTML+CSS as interface that was designed as document framework and not as application interface building framework. That is why we need a back end and front end frameworks.

[bawolff]

Nobody would use cgi for (a) (cgi integrates with webservers, so you already have one to serve your static documents).

You still care about xss (and other vulns, although the technology the grandparent mentioned is specificly for xss) in case b just like case c.

- you might host other things on that domain (or even subdomain, which is a lot trickier but not impossible to attack), and this could be a launching point of an attack.

- attackers might rewrite your page to mislead people, e.g. as part of a phishing attack, to harm your reputation or just to redirect to advertisers.

The impact of any security vulnerability is going to depend on what you are doing and what you have to lose. It seems less significant in case B, but its a mistake to extrapolate as its impossible to tell without business-specific context. Maybe the simple list page is listing out life-saving information.

[bawolff]

If we're talking something written in c, its at least as easy as not having memory safety vulnerabilities ;)

[wazoox]

For these there's good old "perl -T" :)

[czx4f4bd]

How does perl -T protect against XSS?

[bawolff]

Its dynamic taint checking - it tries to keep track of which variables are user controlled (tainted) and prevent you from using them unsafely.

As a strategy for dealing with xss, its fallen out of favour, but static taint analysis, which is the same thing but not at runtime and less accurate is still super popular in big shops as a CI step.

As an approach though its more a way to make sure you dont screw up as opposed to a way to solve the problem in general.