Wapp

Check-in [7be9077b84]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More documentation tweaks.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 7be9077b848c473814f6d5a801527ce2152d94953d6552e8eb2b3658f2fc1042
User & Date: drh 2019-03-06 23:12:35
Context
2019-03-07
13:34
Documentation updates: improvements to the description of URL mapping and CGI variables. check-in: 2eac47dda7 user: drh tags: trunk
2019-03-06
23:12
More documentation tweaks. check-in: 7be9077b84 user: drh tags: trunk
22:49
Documentation tweaks. check-in: ced8768917 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Show Whitespace Changes Patch

Changes to docs/commands.md.

48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
     the %-quotes.  Use "\[" instead.

> >  <b>Caution #2:</b> The %html() and similar %-substitutions are parsed
     using a regexp, which means that they cannot do matching parentheses.
     The %-substitution is terminated by the first close parenthesis, not the
     first matching close-parenthesis.

  +  **wapp-trim** _TEXT_  
     Just like wapp-subst, this routine appends _TEXT_ to the web page
     under construction, using the %html, %url, %qp, %string, and %unsafe
     substitutions.  The difference is that this routine also removes
     surplus whitespace from the left margin, so that if the _TEXT_
     argument is indented in the source script, it will appear at the
     left margin in the generated output.








|







48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
     the %-quotes.  Use "\&#91;" instead.

> >  <b>Caution #2:</b> The %html() and similar %-substitutions are parsed
     using a regexp, which means that they cannot do matching parentheses.
     The %-substitution is terminated by the first close parenthesis, not the
     first matching close-parenthesis.

  +  <a name='wapp-trim'></a>**wapp-trim** _TEXT_  
     Just like wapp-subst, this routine appends _TEXT_ to the web page
     under construction, using the %html, %url, %qp, %string, and %unsafe
     substitutions.  The difference is that this routine also removes
     surplus whitespace from the left margin, so that if the _TEXT_
     argument is indented in the source script, it will appear at the
     left margin in the generated output.

Changes to docs/security.md.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

21
22
23
24
25
26
27

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

43
44
45
46
47
48
49
50
51
52

53
54
55
56
57
58
59
Security Considerations
=======================

Wapp strives for security by default.  Applications can disable security
features on an as-needed basis, but the default setting for security
features is always "on".

Security features in Wapp include the following:

  1.  The default
      [Content Security Policy](https://en.wikipedia.org/wiki/Content_Security_Policy)
      of "CSP"
      for all Wapp applications is _default-src 'self'_.  In that mode,
      resources must all be loaded from the same origin, the use of
      eval() and similar commands in javascript is prohibited, and
      no in-line javascript or CSS is allowed.  These limitations help
      keep applications safe from 
      [XSS attacks](https://en.wikipedia.org/wiki/Cross-site_scripting)
      attacks, even in the face of application coding errors. If these
      restrictions are too severe for an application, the CSP can be

      relaxed using the "wapp-content-security-policy" command.

  2.  Access to GET query parameters and POST parameters is prohibited
      unless the origin of the request is the application itself, as
      determined by the Referrer field in the HTTP header. This feature
      helps to prevent
      [Cross-site Request Forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery)

      attacks. The "wapp-allow-xorigin-params" command can be used to
      disable this protection on a case-by-case basis.

  3.  Cookies, query parameters, and POST parameters are automatically
      decoded before they reach application code. There is no risk
      that the application program will forget a decoding step or
      accidently miscode a decoding operation.

  4.  Cookies, query parameters, and POST parameters are silently discarded
      unless their names begin with a lower-case letter and contain only
      alphanumerics, underscores, and minus-signs.  Hence, there is no risk
      that unusual parameter names can cause quoting problems or other
      vulnerabilities.

  5.  Reply text generated using the "wapp-subst" and "wapp-trim" commands

      automatically escapes generated text so that it is safe for inclusion
      within HTML, within a javascript or JSON string literal, as a URL,
      or as the value of a query parameter. As long as the application
      programmer is careful to always use "wapp-subst" and/or "wapp-trim"
      to generate replies, there is little risk of injection attacks.

  6.  If the application is launched on a command-line with the --lint
      option, then instead of running the application, Wapp scans the
      application code looking for constructs that are unsafe.  Unsafe
      constructs include things such as using "wapp-subst" with an argument

      that is not contained within {...}.

Part of what makes Wapp easy to use is that it helps free application
developers from the worry of accidently introducing security vulnerabilities
via programming errors.  Of course, no framework is fool-proof.  Developers
still must be aware of security.  Wapp does not prevent every error, but
it does help make writing a secure application easier and less stressful.







|












>
|






>
|
|












|
>









|
>







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Security Considerations
=======================

Wapp strives for security by default.  Applications can disable security
features on an as-needed basis, but the default setting for security
features is always "on".

Security features in Wapp include:

  1.  The default
      [Content Security Policy](https://en.wikipedia.org/wiki/Content_Security_Policy)
      of "CSP"
      for all Wapp applications is _default-src 'self'_.  In that mode,
      resources must all be loaded from the same origin, the use of
      eval() and similar commands in javascript is prohibited, and
      no in-line javascript or CSS is allowed.  These limitations help
      keep applications safe from 
      [XSS attacks](https://en.wikipedia.org/wiki/Cross-site_scripting)
      attacks, even in the face of application coding errors. If these
      restrictions are too severe for an application, the CSP can be
      relaxed or disabled using the 
      "[wapp-content-security-policy](commands.md#csp)" command.

  2.  Access to GET query parameters and POST parameters is prohibited
      unless the origin of the request is the application itself, as
      determined by the Referrer field in the HTTP header. This feature
      helps to prevent
      [Cross-site Request Forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery)
      attacks. The 
      "[wapp-allow-xorigin-params](commands.md#allow-xorigin)" command 
      can be used to disable this protection on a case-by-case basis.

  3.  Cookies, query parameters, and POST parameters are automatically
      decoded before they reach application code. There is no risk
      that the application program will forget a decoding step or
      accidently miscode a decoding operation.

  4.  Cookies, query parameters, and POST parameters are silently discarded
      unless their names begin with a lower-case letter and contain only
      alphanumerics, underscores, and minus-signs.  Hence, there is no risk
      that unusual parameter names can cause quoting problems or other
      vulnerabilities.

  5.  Reply text generated using the "[wapp-subst](commands.md#wapp-subst)"
      and "[wapp-trim](commands.md#wapp-trim)" commands
      automatically escapes generated text so that it is safe for inclusion
      within HTML, within a javascript or JSON string literal, as a URL,
      or as the value of a query parameter. As long as the application
      programmer is careful to always use "wapp-subst" and/or "wapp-trim"
      to generate replies, there is little risk of injection attacks.

  6.  If the application is launched on a command-line with the --lint
      option, then instead of running the application, Wapp scans the
      application code looking for constructs that are unsafe.  Unsafe
      constructs include things such as using 
      "[wapp-subst](commands.md#wapp-subst)" with an argument
      that is not contained within {...}.

Part of what makes Wapp easy to use is that it helps free application
developers from the worry of accidently introducing security vulnerabilities
via programming errors.  Of course, no framework is fool-proof.  Developers
still must be aware of security.  Wapp does not prevent every error, but
it does help make writing a secure application easier and less stressful.