| Age | Commit message (Collapse) | Author |
|---|
|
After format string checks were activated in libubox the compiler
started to complain about multiple missuses in uhttpd. This fixes the
format strings without changing the behavior.
blobmsg_get_string() just checks if the parameter is not NULL and then
calls blobmsg_data() and casts the result.
I think non of these problem is security relevant.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
|
Escape untrusted input like the request URL or filesystem paths in HTML
outputs such as the directory listing or 404 error messages.
This fixes certain XSS vulnerabilities which can be leveraged to further
exploit the system.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
The uh_htmlescape() function returns a copy of the given string with the
HTML special characters `<`, `>`, `"` and `'` replaced by HTML entities in
hexadecimal notation.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
The special prefix of "/" should match any url by definition but the final
assertion which ensures that the matched prefix ends in '\0' or '/' is causing
matches against the "/" prefix to fail.
Add some extra code to handle this special case to implemented the expected
behaviour.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
The two commits
5162e3b0ee7bd1d0fd6e75e1ca7993a1834b5291
"allow request handlers to disable chunked reponses"
and
618493e378e2239f0d30902e47adfa134e649fdc
"file: disable chunked encoding for file responses"
broke the chunked transfer encoding handling for proc responses in keep-alive
connections that followed a file response with http status 204 or 304.
The effect of this bug is that cgi responses following a 204 or 304 one where
sent neither in chunked encoding nor with a content-length header, causing
browsers to stall until the keep alive timeout was reached.
Fix the logic flaw by inverting the chunk prevention flag in the client state
and by testing the chunked encoding preconditions every time instead of
once upon client (re-)initialization.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
According to RFC2616 10.2.5 and 10.3.5, 204 and 304 responses MUST NOT contain any
message body, therfore do not emit an EOF chunk for such responses.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
In order to support cross-domain AJAX requests to the /ubus endpoint
we need to implement the Cross-Origin Resource Sharing (CORS) spec
in the ubus plugin.
- Implement a new option "-X" to enable CORS support in ubus
- Implement rudimentary support for "OPTIONS" HTTP requests
- Implement essential CORS headers the ubus plugin
The current CORS response headers merely reflect the request headers
sent by the client, this way any requesting origin is automatically
allowed. Cross-domain cookies (Access-Control-Allow-Credentials) are
unconditionally enabled.
Restricting permitted origins and toggle the credential accepting can
be made configurable in a future commit to allow more fine grained
control over permitted AJAX clients.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
The ubus plugin calls blocking ubus functions that loop back into
uloop_run. Protect the client data structure with refcounting to ensure
that the outer uloop_run call does not clean up the data that the inner
uloop_run call is still processing.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
|
|
|
|
signed/unsigned casts
|
|
|
|
|
|
|
|
|
|
|
