A network's QoS form whose rate was not a whole number (abc, 1.5) made
wvmNetwork.set_qos raise a ValueError that the view did not catch: the
request ended in a server error. The page's pattern stops this in a
browser, but the server must refuse it too. set_qos now says "QoS rates
must be whole numbers", and the view reports that, as it does a libvirt
error, and goes back to the network's page.
The create-network form only checked the characters of its subnets, so
192.0.2.0/33 or 999.0.2.0/24 passed and network_size raised a
ValueError: the user got a server error instead of a message. So did a
subnet too small for the gateway, DHCP range and broadcast address that
network_size derives (0.0.0.0/32, 255.255.255.255/32), and 192.0.2.0/31
or a bare address gave an inverted DHCP range.
Each subnet field now parses its value as a network of its IP version
and refuses it with a field error otherwise. An IPv4 prefix must be /30
or shorter; the IPv6 prefix must be /64, which the view checked after
the form and now the form does.
Four lookups built XPath expressions from values that come from
requests (CodeQL py/xpath-injection, plus get_capabilities, which
CodeQL did not flag; the pages are for superusers):
- The architecture in the create wizard's URLs went into
arch[@name='...'] in get_emulator, get_machine_types and
get_capabilities: "nope' or '1'='1" matched every architecture. It is
now an XPath variable ($arch), which is never parsed as XPath.
- Network filter rules were found with a predicate built from the
posted action, direction and priority: a quote raised SyntaxError (an
error page). The rule is now found by comparing its attributes.
- unset_qos put the posted direction into the path, so "*" removed
every bandwidth setting. It accepts inbound and outbound, as set_qos
does; the network page shows an error for anything else.
No other XPath in vrtManager is built from a value; the remaining
expressions are constants. The tests fail on the previous code.
