Difference between revisions of "Web App"
From MgmtWiki
(→Solutions) |
(→Problems) |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | A digital [[User Experience]] that is operating on a [[User Device]] and is typically supplied by the [[Web Site]]. Also known as a Progressive Web | + | A digital [[User Experience]] that is operating in an interpreter on a [[User Device]] and is typically supplied by the [[Web Site]]. Also known as a [[Progressive Web App]] (PWA). |
| + | |||
| + | Warning: Some references to [[Web App]]s describe the web app as running on the server. That is not what this page is about. | ||
==Context== | ==Context== | ||
| − | *As the functionality of the Web Browsers and HTML 5 becomes ever more capable, a [[Web Site]] can | + | *As the functionality of the Web Browsers and HTML 5 becomes ever more capable, a [[Web Site]] can load a [[Web App]] entirely within the browser. |
| − | *There is no real demarcation between a [[Web Site]] and a [[Web App]] except for the existence of a [[Web App Manifest]]. | + | *There is no real demarcation between a [[Web Site]] and a [[Web App]] loaded from that site except for the existence of a [[Web App Manifest]]. |
*Typically the [[Native App]] will run on a [[User Device]] in the user's physical possession, but it is possible that the agent is running on a service in [[The Cloud]]. | *Typically the [[Native App]] will run on a [[User Device]] in the user's physical possession, but it is possible that the agent is running on a service in [[The Cloud]]. | ||
*The [[Native App]] may act like a browser and supply an HTTP user agent string, but it should not be considered to be a [[User Agent]]. | *The [[Native App]] may act like a browser and supply an HTTP user agent string, but it should not be considered to be a [[User Agent]]. | ||
| Line 11: | Line 13: | ||
==Problems== | ==Problems== | ||
*The user will be hard pressed to distinguish between a [[Web App]] and a [[Native App]] which is a problem as the operating of the environment of the [[Web App]] is constrained by the browser that is selected by the user, while the [[Native App]] can ask for access to device capabilities that are not available to the [[Web App]]. | *The user will be hard pressed to distinguish between a [[Web App]] and a [[Native App]] which is a problem as the operating of the environment of the [[Web App]] is constrained by the browser that is selected by the user, while the [[Native App]] can ask for access to device capabilities that are not available to the [[Web App]]. | ||
| + | |||
| + | Progressive web apps (PWAs) are web applications that use modern web technologies to provide a native-like experience for users. They can be installed on the home screen of mobile devices or desktop computers, and they can work offline, send push notifications, and access device features. However, PWAs also face some security issues that need to be considered by developers and users. Some of the security issues with PWAs are: | ||
| + | |||
| + | * Broken access control: This occurs when a PWA fails to properly restrict what users can do or see on the website. For example, a user may be able to access or modify another user’s account, view sensitive information, or perform unauthorized actions. This can lead to data theft, fraud, identity impersonation, or denial of service attacks1. | ||
| + | * Cryptographic failures: This occurs when a PWA uses weak or outdated encryption algorithms, keys, or protocols to protect data in transit or at rest. For example, a PWA may use HTTP instead of HTTPS, store passwords in plain text, or use insecure random number generators. This can lead to data interception, modification, or decryption by attackers2. | ||
| + | * Injection: This occurs when a PWA accepts untrusted input from users or other sources and executes it as part of a command or query. For example, a PWA may allow a user to enter SQL statements in a search box and run them on the database. This can lead to data loss, corruption, disclosure, or unauthorized access2. | ||
| + | * Cross-site scripting (XSS): This occurs when a PWA allows attackers to inject malicious code into web pages that are viewed by other users. For example, a PWA may display user comments without sanitizing them and allow attackers to embed JavaScript code that steals cookies, redirects users, or displays fake content. This can lead to session hijacking, phishing, malware infection, or defacement2. | ||
| + | These are just some of the security issues that PWAs may encounter. There are many other types of vulnerabilities and attacks that can affect PWAs, such as cross-site request forgery (CSRF), denial of service (DoS), insecure deserialization, broken authentication, and more2. Therefore, it is important for developers and users to follow best practices and guidelines to secure their PWAs and protect their data. Some of the tips on how to secure PWAs are: | ||
| + | |||
| + | Implement strong access control policies and mechanisms that limit user privileges and actions based on their roles and needs. | ||
| + | Use secure encryption methods and protocols that ensure data confidentiality, integrity, and authenticity in transit and at rest. | ||
| + | Validate and sanitize all user input and output to prevent injection attacks and XSS attacks. | ||
| + | Update and patch all components and dependencies of the PWA to fix known vulnerabilities and bugs. | ||
| + | Perform regular security testing and auditing of the PWA to identify and remediate any weaknesses or flaws. | ||
| + | |||
| + | |||
| + | |||
| + | These are just some of the security problems that web applications may encounter. There are many other types of vulnerabilities and attacks that can affect web applications, such as cross-site request forgery (CSRF), denial of service (DoS), insecure deserialization, broken authentication, and more3. Therefore, it is important for web developers and administrators to follow best practices and guidelines to secure their web applications and protect their users and data. Some of the tips on how to secure web applications are: | ||
| + | |||
| + | Implement strong access control policies and mechanisms that limit user privileges and actions based on their roles and needs. | ||
| + | Use secure encryption methods and protocols that ensure data confidentiality, integrity, and authenticity in transit and at rest. | ||
| + | Validate and sanitize all user input and output to prevent injection attacks and XSS attacks. | ||
| + | Update and patch all components and dependencies of the web application to fix known vulnerabilities and bugs. | ||
| + | Perform regular security testing and auditing of the web application to identify and remediate any weaknesses or flaws4. | ||
| + | I hope this helps you understand the security problems with web apps and how to prevent them. | ||
==Solutions== | ==Solutions== | ||
| Line 17: | Line 44: | ||
* Web apps can be downloaded by the web site at any time. To be labeled as an app by the device, the user will be asked to allow that. One it is allowed, the app can be updated at any time by the web site. | * Web apps can be downloaded by the web site at any time. To be labeled as an app by the device, the user will be asked to allow that. One it is allowed, the app can be updated at any time by the web site. | ||
* [https://www.chromium.org/blink/webcrypto WebCrypto was enabled in Chrome 37] 2014-08-26. | * [https://www.chromium.org/blink/webcrypto WebCrypto was enabled in Chrome 37] 2014-08-26. | ||
| + | * [https://webkit.org/blog/7790/update-on-web-cryptography/ Web Cryptography was enabled on webkit] for Apple Safari and related packages on 2017-07-21. | ||
| + | * It is not at all clear if hardware protection is provided for keys created by web apps. [https://w3c.github.io/webcrypto/ See the spec.] <blockquote>While it is assumed that most user agents will be interacting with a cryptographic provider that is implemented purely in software, it is not required by this specification. As a result, the capabilities of some implementations may be limited by the capabilities of the underlying hardware, and, depending on how the user has configured the underlying cryptographic library, this may be entirely opaque to the User Agent.</blockquote> | ||
| + | ===Trusted Web Activity=== | ||
| + | * [https://developers.google.com/web/android/trusted-web-activity TWA on Google dev site]. | ||
==References== | ==References== | ||
<references /> | <references /> | ||
===Internal Material=== | ===Internal Material=== | ||
| + | #[[Apps on User Devices]] wiki page comparing web app and native app issues | ||
#[[Native App Security]] page in this wiki | #[[Native App Security]] page in this wiki | ||
#[[Native App Privacy]] page in this wiki | #[[Native App Privacy]] page in this wiki | ||
#[https://tcwiki.azurewebsites.net/index.php?title=Native_App W3C page on web apps] best practices as of (2010-12-10). | #[https://tcwiki.azurewebsites.net/index.php?title=Native_App W3C page on web apps] best practices as of (2010-12-10). | ||
#[[Progressive Web App]] page in this wiki | #[[Progressive Web App]] page in this wiki | ||
| + | |||
===External Material=== | ===External Material=== | ||
# [https://developer.mozilla.org/en-US/docs/Web/API Web APIs] When writing code for the Web, there are a great many Web APIs available. The link contains a list of all the APIs and interfaces (object types) that you may be able to use while developing your Web app or site. Web APIs are typically used with JavaScript, although this doesn't always have to be the case.] | # [https://developer.mozilla.org/en-US/docs/Web/API Web APIs] When writing code for the Web, there are a great many Web APIs available. The link contains a list of all the APIs and interfaces (object types) that you may be able to use while developing your Web app or site. Web APIs are typically used with JavaScript, although this doesn't always have to be the case.] | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
| + | [[Category: Web]] | ||
Latest revision as of 14:52, 26 September 2023
Contents
Full Title or Meme
A digital User Experience that is operating in an interpreter on a User Device and is typically supplied by the Web Site. Also known as a Progressive Web App (PWA).
Warning: Some references to Web Apps describe the web app as running on the server. That is not what this page is about.
Context
- As the functionality of the Web Browsers and HTML 5 becomes ever more capable, a Web Site can load a Web App entirely within the browser.
- There is no real demarcation between a Web Site and a Web App loaded from that site except for the existence of a Web App Manifest.
- Typically the Native App will run on a User Device in the user's physical possession, but it is possible that the agent is running on a service in The Cloud.
- The Native App may act like a browser and supply an HTTP user agent string, but it should not be considered to be a User Agent.
- The Native App may act like a web server by registering Native App URI Handlers so that it will receive registered URLs entered into the browser.
Problems
- The user will be hard pressed to distinguish between a Web App and a Native App which is a problem as the operating of the environment of the Web App is constrained by the browser that is selected by the user, while the Native App can ask for access to device capabilities that are not available to the Web App.
Progressive web apps (PWAs) are web applications that use modern web technologies to provide a native-like experience for users. They can be installed on the home screen of mobile devices or desktop computers, and they can work offline, send push notifications, and access device features. However, PWAs also face some security issues that need to be considered by developers and users. Some of the security issues with PWAs are:
- Broken access control: This occurs when a PWA fails to properly restrict what users can do or see on the website. For example, a user may be able to access or modify another user’s account, view sensitive information, or perform unauthorized actions. This can lead to data theft, fraud, identity impersonation, or denial of service attacks1.
- Cryptographic failures: This occurs when a PWA uses weak or outdated encryption algorithms, keys, or protocols to protect data in transit or at rest. For example, a PWA may use HTTP instead of HTTPS, store passwords in plain text, or use insecure random number generators. This can lead to data interception, modification, or decryption by attackers2.
- Injection: This occurs when a PWA accepts untrusted input from users or other sources and executes it as part of a command or query. For example, a PWA may allow a user to enter SQL statements in a search box and run them on the database. This can lead to data loss, corruption, disclosure, or unauthorized access2.
- Cross-site scripting (XSS): This occurs when a PWA allows attackers to inject malicious code into web pages that are viewed by other users. For example, a PWA may display user comments without sanitizing them and allow attackers to embed JavaScript code that steals cookies, redirects users, or displays fake content. This can lead to session hijacking, phishing, malware infection, or defacement2.
These are just some of the security issues that PWAs may encounter. There are many other types of vulnerabilities and attacks that can affect PWAs, such as cross-site request forgery (CSRF), denial of service (DoS), insecure deserialization, broken authentication, and more2. Therefore, it is important for developers and users to follow best practices and guidelines to secure their PWAs and protect their data. Some of the tips on how to secure PWAs are:
Implement strong access control policies and mechanisms that limit user privileges and actions based on their roles and needs. Use secure encryption methods and protocols that ensure data confidentiality, integrity, and authenticity in transit and at rest. Validate and sanitize all user input and output to prevent injection attacks and XSS attacks. Update and patch all components and dependencies of the PWA to fix known vulnerabilities and bugs. Perform regular security testing and auditing of the PWA to identify and remediate any weaknesses or flaws.
These are just some of the security problems that web applications may encounter. There are many other types of vulnerabilities and attacks that can affect web applications, such as cross-site request forgery (CSRF), denial of service (DoS), insecure deserialization, broken authentication, and more3. Therefore, it is important for web developers and administrators to follow best practices and guidelines to secure their web applications and protect their users and data. Some of the tips on how to secure web applications are:
Implement strong access control policies and mechanisms that limit user privileges and actions based on their roles and needs. Use secure encryption methods and protocols that ensure data confidentiality, integrity, and authenticity in transit and at rest. Validate and sanitize all user input and output to prevent injection attacks and XSS attacks. Update and patch all components and dependencies of the web application to fix known vulnerabilities and bugs. Perform regular security testing and auditing of the web application to identify and remediate any weaknesses or flaws4. I hope this helps you understand the security problems with web apps and how to prevent them.
Solutions
- Certification of the Web App please refer to page Web App Manifest.
Security
- Web apps can be downloaded by the web site at any time. To be labeled as an app by the device, the user will be asked to allow that. One it is allowed, the app can be updated at any time by the web site.
- WebCrypto was enabled in Chrome 37 2014-08-26.
- Web Cryptography was enabled on webkit for Apple Safari and related packages on 2017-07-21.
- It is not at all clear if hardware protection is provided for keys created by web apps. See the spec.
While it is assumed that most user agents will be interacting with a cryptographic provider that is implemented purely in software, it is not required by this specification. As a result, the capabilities of some implementations may be limited by the capabilities of the underlying hardware, and, depending on how the user has configured the underlying cryptographic library, this may be entirely opaque to the User Agent.
Trusted Web Activity
References
Internal Material
- Apps on User Devices wiki page comparing web app and native app issues
- Native App Security page in this wiki
- Native App Privacy page in this wiki
- W3C page on web apps best practices as of (2010-12-10).
- Progressive Web App page in this wiki
External Material
- Web APIs When writing code for the Web, there are a great many Web APIs available. The link contains a list of all the APIs and interfaces (object types) that you may be able to use while developing your Web app or site. Web APIs are typically used with JavaScript, although this doesn't always have to be the case.]
