Error on sanitizing resource url

[armaserg]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ X] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

Error is throwing when I'm trying to sanitize unsafe resource url (for iframe src)

Expected behavior

unsafe resource url should be sanitized to safe string

Minimal reproduction of the problem with instructions

this.sanitizer.sanitize(SecurityContext.RESOURCE_URL, 'data:text/html,<script>alert(1)</script>') throws error
https://stackblitz.com/edit/angular-9zjuc7

What is the motivation / use case for changing the behavior?

URL provided by user should be used as src for iframe

Environment

Angular version: 7.0.1

 

[chaosmonster]

Lookint at your stackblitz the expected xss attack seems legit. Because you try to add a script tag in an url. Looking at this switch case I think the SafeResourceUrlservice might be more helpful.

[trotyl]

It's by design, SecurityContext.RESOURCE_URL is meant for application data (like JSON files), the sanitization would always break application logic, so an explicit error must be throw. Otherwise you should use SecurityContext.URL instead which will just print warning.

[armaserg]

Sorry, but according to docs: https://angular.io/api/platform-browser/DomSanitizer, ResourceUrl should be used for "<script src>, or <iframe src>"

[trotyl]

The only point is whether you expect an untrusted URL to break the application, and the only purpose for RESOURCE_URL to exist is for throwing that error explicit.

There is no different rule in sanitizing URLs.

[chaosmonster]

The documentation says to use bypassSecurityTrustResourceUrl for <ifrmae> your stackblitz uses DomSanitizer.sanitze

[armaserg]

bypassSecurityTrustResourceUrl can't be used for data provided by users.

With SecurityContext.URL it works, but not sure does it work really correct... It leaves whole unsafe string and prefix it with "unsafe:" (good thing: alert(1) doesn't execute)

https://stackblitz.com/edit/angular-n7pwhf ( @chaosmonster try to uncomment commented line and you'll see that simple bypassSecurityTrustResourceUrl is not sulution)

[trotyl]

@armaserg The entire idea of URL sanitization is making it an invalid URL that will not work anyway, there's no strip-some-part option.

[armaserg]

ok. in this case it works correct.
so, is this.sanitizer.bypassSecurityTrustResourceUrl(this.sanitizer.sanitize(SecurityContext.URL, this.iframeSrcProvidedByUser)) only option in my situation?

[trotyl]

The Sanitizer service is only designed for template binding in Angular, not your application logic. And if you do use it in application logic, then you can just report error about the vulnerable URL to user and stop processing, rather than pass the already known-vulnerable URL to Angular again.

So so-called Sanitizer in Angular is just a Remainder, it cannot validate something really being unsafe or not, but just let you know the vulnerability exists for anything possible to be unsafe. And you can either tell Angular something is safe or process it by other means.

[armaserg]

Ok. But why does it automatically sanitize src for image but throws error for iframe src?
https://stackblitz.com/edit/angular-n7pwhf

[trotyl]

That’s the role of RESOURCE_URL, it’s considered a critical path of the application, so Angular would never cause an incomplete application by implicit sanitization, but let you know it must be handled by developers.

You're responsible to make sure unsafe value not being passed to Angular by either trust the URL or avoid accepting user inputs, and the Sanitizer will remind you while keep the application safe only when you fails to do that.

[armaserg]

ok. thanks...

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}