Now set the correct base URL for each article's webview, and now load app JavaScripts as WebKit "user" scripts.

Setting the real base URL (rather than using a file URL pointing to the app's Resources folder) allows relative URLs to work correctly within the article, such as for images, and is compatible with Cross-Site-Origin policies that restrict use of resources outside of the origin domain.

It also implicitly eliminates access to the local file system from within the webview, as the use of a non-file base URL makes WebKit treats the webview's content as being from a remote server, and its default security policy is to then disallow local file access (except with explicit user action, such as drag-and-drop or via an `input` form element).

Note: the base URL is currently typically taken from the feed itself (specifically the "link" feed (channel) metadata).  That is controlled by the feed author (or a man-in-the-middle attacker).  It should perhaps be validated to ensure it's actually an HTTP/HTTPS URL, to prevent security problems.

The app-specific JavaScripts - used for fixing styling issues and the like - are now formally loaded as extensions to the web page, "user scripts" in WebKit parlance.  They're isolated to their own JavaScript world - meaning they can't be seen or manipulated by JavaScript from the feed article itself, and are more secure as a result.

Fixes #4156.

Co-Authored-By: Brent Simmons <1297121+brentsimmons@users.noreply.github.com>
This commit is contained in:
Wade Tregaskis
2023-11-22 13:41:58 -08:00
parent e9f26c9adc
commit bc15440ded
5 changed files with 34 additions and 20 deletions

View File

@@ -5,15 +5,6 @@
<style>
[[style]]
</style>
<script src="main.js"></script>
<script src="main_ios.js"></script>
<script src="newsfoot.js" async="async"></script>
<script type="text/javascript">
document.addEventListener("DOMContentLoaded", function(event) {
window.scrollTo(0, [[windowScrollY]]);
processPage();
})
</script>
<base href="[[baseURL]]">
</head>
<body>