Page MenuHomePhabricator

Phabricator link on Internal Server Error page is reported as an XSS attack by noscript
Closed, ResolvedPublic1 Estimated Story Points

Description

This causes the main Phabricator page to load. Since we want users to report issues, we need to figure out the difference between the link in the footer and on the error page.

Event Timeline

Matthewrbowker set the point value for this task to 1.

It's the file name in the task description. Logging output:

[NoScript InjectionChecker] JavaScript Injection in ///maniphest/task/create/?title=PLEASE%20REPLACE%20WITH%20A%20DESCRIPTION%20OF%20THE%20ERROR&priority=75&projects=Tool-labs-tools-xtools&description=```/var/www/src/Xtools/Edit.php:%20103%20-%20Error:%20Call%20to%20a%20member%20function%20format()%20on%20boolean```(function anonymous(
) {
```/var/www/src/Xtools/Edit.php:%20103%20-§:§§§§§§()§§``` /* COMMENT_TERMINATOR */
DUMMY_EXPR
})
[NoScript XSS] Sanitized suspicious request. Original URL [https://phabricator.wikimedia.org/maniphest/task/create/?title=PLEASE%20REPLACE%20WITH%20A%20DESCRIPTION%20OF%20THE%20ERROR&priority=75&projects=Tool-labs-tools-xtools&description=```/var/www/src/Xtools/Edit.php:%20103%20-%20Error:%20Call%20to%20a%20member%20function%20format()%20on%20boolean```] requested from [http://xtools.wmflabs.org/articleinfo/en.wikipedia.org/Thomas%20Jefferson]. Sanitized URL: [https://phabricator.wikimedia.org/#42521639302495773499].
Samwilson subscribed.

It seems like even with replacing the filename with just the class name this could still be a bit fragile — what if there's a file name in the error message at some point?

I think the most useful thing to submit in the bug report is the full current URL that the user is accessing, query string and all. No, actually just the timestamp really, because we can look in the log for the rest.

(But, the above PR solves this for now, so I'm also happy to close this till some further problem arises!)

It seems like even with replacing the filename with just the class name this could still be a bit fragile — what if there's a file name in the error message at some point?

I think the most useful thing to submit in the bug report is the full current URL that the user is accessing, query string and all. No, actually just the timestamp really, because we can look in the log for the rest.

(But, the above PR solves this for now, so I'm also happy to close this till some further problem arises!)

The full URL may still be seen as an XSS attempt... that's why I went with the class instead. The more long term solution might be full path if we could figure out a way to URL encode it.