End of XSS?

[Azareal]

There are quite a few technologies these days for countering XSS like content security policy headers, template escaping, contextual escaping in templates, etc.

With a content security policy, you can restrict scripts so that only external files served from the same domain will be allowed to run and anything else, including inline scripts will be killed off. You can also pass a number of hashes in headers, so that only scripts which match specific hashes will run, this might be useful if you're loading a script off a third party CDN.

There are also nonces where you generate a random string and the one in the script tag has to match the one in the header for a particular script to run.

With contextual escaping, the template system is aware of whether it's in a JS block, etc. and will apply the appropriate escaping rather than blindly doing entity escapes intended for HTML or other silliness. This is fairly common in more modern languages these days.

There are plenty of old legacy systems which will always be affected, but could it be that the dreaded XSS will vanish from the world?

 

[Ghost]

I don't think that the dreaded XSS will disappear. XSS has always been about finding mistakes from programmers, but the standards have been there for a while. Yes, there are systems that do it automatically, but it relies on programmers actually implementing those safeguards.

Yes, forums, blogs, etc are definitely more safe, and websites (with the creation of Wix, WordPress, etc) are safer too.. However, there are still many web systems being created that come from scratch. These are the main targets these days of hackers. They search for websites that are NOT on the main web softwares. One major problem for many of these sites is that they go for cheap developers that take shortcuts. They may not protect everything and this leads to possible XSS attacks. So while most of the internet IS running on secure web platforms, a lot of major sites (especially start up companies with proprietary software) that need custom features & software are actually the most insecure. This means that while hackers have less overall targets, the targets they DO find actually end up being bigger hacks than in the past. Hackers also use scripts to scour the internet and find pages that are XSS vulnerable automatically. So this makes it easier to find targets than in the past, even with less overall targets. For major web software, the biggest vulnerability is with custom plugins & features that are not fully or adequately approved by the original software developer. This is even more true when a website pays a developer to create a custom plugin/mod/addon that isn't distributed/tested & leads that one site to be vulnerable.

 

[Deleted member 44219]

Never heard of XSS. But it does sound similar to RSS.

From what I've read from both Ghost's reply and a quick search on Google, it's cross-site scripting and has something to do with hacking.

 

[Azareal]

I don't think that the dreaded XSS will disappear. XSS has always been about finding mistakes from programmers, but the standards have been there for a while. Yes, there are systems that do it automatically, but it relies on programmers actually implementing those safeguards.

Yes, forums, blogs, etc are definitely more safe, and websites (with the creation of Wix, WordPress, etc) are safer too.. However, there are still many web systems being created that come from scratch. These are the main targets these days of hackers. They search for websites that are NOT on the main web softwares. One major problem for many of these sites is that they go for cheap developers that take shortcuts. They may not protect everything and this leads to possible XSS attacks. So while most of the internet IS running on secure web platforms, a lot of major sites (especially start up companies with proprietary software) that need custom features & software are actually the most insecure. This means that while hackers have less overall targets, the targets they DO find actually end up being bigger hacks than in the past. Hackers also use scripts to scour the internet and find pages that are XSS vulnerable automatically. So this makes it easier to find targets than in the past, even with less overall targets. For major web software, the biggest vulnerability is with custom plugins & features that are not fully or adequately approved by the original software developer. This is even more true when a website pays a developer to create a custom plugin/mod/addon that isn't distributed/tested & leads that one site to be vulnerable.

Many major frameworks and template systems will automatically escape things for you and actually make development quicker and easier.
People really shouldn't be entirely inventing the wheel in 2019.

Also, your business can be fined by the European Union for complete incompetence when it comes to security, these days.

Never heard of XSS. But it does sound similar to RSS.

From what I've read from both Ghost's reply and a quick search on Google, it's cross-site scripting and has something to do with hacking.

XSS is a somewhat silly name Microsoft gave it when they discovered it in '99 (Microsoft discovered SQL Injections in '98, but didn't really push substantial protections against it).
It's basically an attacker finding a way to squeak a script tag onto the page and running JS that they're not supposed to run.

It's one of the great classic web vulnerability classes. SQL Injection, XSS, CSRF, etc.
Usually if you're developing anything for the web, you should be aware of them.

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_2017_Project Owasp usually has some information, although it's not good to solely rely on them.

 

[Ghost]

Many major frameworks and template systems will automatically escape things for you and actually make development quicker and easier.
People really shouldn't be entirely inventing the wheel in 2019.\

I want to address this. It's not reinventing the wheel. There are many reasons to avoid frameworks. For one, you end up relying on something that not everyone knows. For example, if a client wants us to work on Laravel we charge around $15 more per hour than our normal core PHP rate because not all of our developers have Laravel experience. If a client wants Codeigniter, we charge more per hour. Similarly, if a client is on WordPress, we charge more per hour than making a feature from scratch. It's not always easier and quicker to use a framework unless the developer knows that specific framework. So it's definitely something that depends on a few things:
- do the developers all know the same framework(s)
- do the benefits of the framework outweigh the cons
- are there any security concerns?
While more established frameworks are more widely known and pretty secure, they're not the answer to everything. Many sites are way too small to need a framework. You really only need frameworks for large websites and even then you can build it pretty quickly with core PHP. It's not hard to make a secure login system that lets users login, save data, etc. I'm a huge fan of frameworks, but it's not hard at all to sanitize user data and automatically escape data. The main reason people use frameworks is because it does things that are tedious (even if still easy) to do. The problem is that a lot of developers work with the frameworks, but don't know how to actually write the original code. It's similar to how a lot of people know jQuery, but not core JavaScript. Sometimes the frameworks actually do lead to security concerns because the developers working on them try to implement custom features and use the code wrong because they've never built anything from scratch.

Additionally, frameworks cause you to rely on third party code. Of course you can modify the framework, but that makes updating more difficult. Personally, we use our own framework when coding for clients. We have functions and classes built for most use cases, so we just use that as a baseline when we build custom systems. We have full control and update it as needed and teach our developers how to actually use it. However not every project requires this and sometimes it's better for us to build from scratch because the client isn't doing anything fancy

 

[Azareal]

I want to address this.

A lot of this is incidentally why I like Go. The language basically has sanitised templating out of the box which you can use with a single import and a bunch of other things.

There are frameworks to make things even easier, but there's more parts included.

Anyway, I'll try to address some of these points:

It's not hard to make a secure login system that lets users login, save data, etc.

This is one of the many reasons many people don't like PHP. It's very easy to vastly overestimate your own abilities and say "this is easy" before slapping together a grossly insecure program.

It's best to leave security matters to experts at Google, Microsoft, Insert a company you find highly competent who practically live for these sorts of problems and are always writing some new paper about a novel way to break TLS (HTTPS uses that).

Additionally, frameworks cause you to rely on third party code.

Everything is third party code in the end including PHP, C#, Go, etc.

it's not hard at all to sanitize user data

Except it isn't when you overlook a line or you use a function you're not supposed to use but the outdated PHP docs tell you to anyway. There is such a thing as being secure by default, so you never risk yourself as badly all the time.

In MyBB, they had a very embarrassing incident where there a SQL Injection vulnerability in the theme selector and half their users table was dumped before they cut it off. These are people who highly pride themselves on security, but who aren't using secure by default frameworks or stacks.

Just the other day, I got bored and casually looked at it's code finding a potential vulnerability which could lead to someone logging in as the administrator, as-well as a few spots to search around in for similar issues. I threw it over to Euan who is in-charge of development and he'll presumably close it all up.

Of course you can modify the framework, but that makes updating more difficult.

You could use a less opinionated framework rather than going full MVC then.

The problem is that a lot of developers work with the frameworks, but don't know how to actually write the original code. It's similar to how a lot of people know jQuery, but not core JavaScript.

Sometimes the frameworks actually do lead to security concerns because the developers working on them try to implement custom features and use the code wrong because they've never built anything from scratch.

I know plenty of people point and laugh at jQuery now, but it solved a lot of problems relating to the different ways browsers handled the DOM at the time. It's a bit worse for wear, but it was a necessary abstraction.

If a paid professional is unable to understand at-least some of the principles behind how the framework and language works, then maybe they should look for a new line of work.

I find it strange how in this industry, we cater to people who don't quite know what they're doing in the name of saving a quick buck, while no one would ever tolerate this sort of nonsense, if they hired someone to wire their home or fix their pipes.

It's like trying to hammer a nail in with a rock as opposed to using real tools, just because more people understand the principle of hammering things in with a rock over a hammer.

 

[Ghost]

Yeah MyBB had a couple issues. Their theme upload in admin panel also allowed people to upload non theme files like shells, so if you had access to admin panel you could take down an entire site. A co-admin could infiltrate the site basically.

I think what you’re saying is all accurate, I’m just also saying that secure code isn’t that hard to write - it truly is forgetfulness that often leads to the vulnerability.

File uploads:
Check extension, strip unwanted chars, check file size

Data inserts:
-FILTER VAR sanitize/validate to make sure data is correct
-prepared queries to avoid SQL injection
- never trust html attributes
- permission checks for user to modify or view any data referenced by an ID

Data display:
- FILTER VAR redundancy
- htmlspecialchars()
- be aware of href= and attribute vulnerabilities

Doing just those things there is quite easy and covers around 99% of the common exploits for SQL injection and XSS.

So while you’re definitely right, I do think it’s possible to avoid frameworks still in 2019

 

[Azareal]

Yeah MyBB had a couple issues. Their theme upload in admin panel also allowed people to upload non theme files like shells, so if you had access to admin panel you could take down an entire site. A co-admin could infiltrate the site basically.

I think what you’re saying is all accurate, I’m just also saying that secure code isn’t that hard to write - it truly is forgetfulness that often leads to the vulnerability.

File uploads:
Check extension, strip unwanted chars, check file size

Data inserts:
-FILTER VAR sanitize/validate to make sure data is correct
-prepared queries to avoid SQL injection
- never trust html attributes
- permission checks for user to modify or view any data referenced by an ID

Data display:
- FILTER VAR redundancy
- htmlspecialchars()
- be aware of href= and attribute vulnerabilities

Doing just those things there is quite easy and covers around 99% of the common exploits for SQL injection and XSS.

So while you’re definitely right, I do think it’s possible to avoid frameworks still in 2019

Speaking of prepared statements, I've seen someone doing something along the lines of this before (can't remember the specific syntax for MySQLi):

$stmt = $db->prepare("SELECT * FROM users where uid = {$_GET['uid']}");
$stmt->execute();

Completely wrong.

As for MyBB, the ACP largely relies on a ring of walls for security, the thing itself basically has no security and you shouldn't assume it does. People are always finding new vulnerabilities in it.

File uploads:

As noted in Eevee's "Fractal of Bad Design", extension checking is defeated by the popular web server Apache which interprets haha.php.png as a PHP file. Also, for years, if you put a null byte before .png, it would end up saved as haha.php

Also, it is possible for an image to a polyglot and to have a script hidden inside the metadata.

Data inserts:

Prepared statements, if I recall, are quite verbose and slow in PHP, so people who are doing things by hand often avoid using them entirely. Also, a user can easily use them incorrectly in contrast to a query builder and it is impossible to parametrise IN() without a query builder.

Data display:

Many modern templates systems (not sure about PHP's frameworks) have contextual escaping, so they will automatically context sensitive escaping for HTML attributes, random blocks and even interpolation inside JavaScript strings.

This is done automatically, so when you inevitably make a mistake in a 80k LOC program, you won't be completely screwed and a bit of paranoia will be freed up for more productive tasks.

 

[Ghost]

You bring up a lot of good points. There are definitely opportunities for huge mistakes
I think libraries are great, but everyone should learn core JS/core PHP/core anything before using the library. My main complaint with them is that if they learn on a library after minimal use of the core language, they'll make more mistakes.

The prepared query example you gave is ridiculous lol. Defeats the purpose of prepared.
The file upload comment raises valid points. I always tell developers to hash the filename, make sure it's unique and upload it like that. That way it's always the final extension, and the raw filename is nothing like the user uploaded. Then you store the original filename in the database for when you display it.

Overall, great points for why people should use libraries and not rebuild the wheel, but I do think that if people would make the mistakes your mentioning then they shouldn't be progressing to a library anyways. It's amazing how many developers can't write an entire web app with core JS/HTML/PHP without some sort of framework/library.