[Oisf-devel] libhtp 0.5.x integration - bug 775
Anoop Saldanha
anoopsaldanha at gmail.com
Mon Jun 17 07:42:15 UTC 2013
Ivan,
Have some questions. Would appreciate if each question can be
addressed individually.
1. While producing the normalized uri, what is the right way to
generate the normalized query string? Can see 2 solutions -
1.1 Duplicate this code section from htp_unparse_uri_noencode( ) -
if (uri->query != NULL) {
bstr *query = bstr_dup(uri->query);
htp_uriencoding_normalize_inplace(query);
bstr_add_c_noex(r, "?");
bstr_add_noex(r, query);
bstr_free(query);
}
2.2 Register htp_config_register_urlencoded_parser( ), and then
use the below code -
if (uri->query != NULL) {
bstr_add_c_noex(r, "?");
size_t tsize = htp_table_size(tx->request_params);
size_t i;
for (i = 0; i < tsize; i++) {
htp_param_t *p =
htp_table_get_index(tx->request_params, i, NULL);
if (p == NULL || p->source != HTP_SOURCE_QUERY_STRING)
continue;
bstr_add_noex(r, p->name);
if (bstr_len(p->value) != 0) {
bstr_add_c_noex(r, "=");
bstr_add_noex(r, p->value);
}
if (i != (tsize - 1))
bstr_add_c_noex(r, "&");
}
Which of these 2 is the right solution?
2. htp_config_register_urlencoded_parser() registers 2 hooks, one for
the request query and the other for the request body. Can libhtp
expose through a conf function the registration of just the query
hook?
3. ?name1&name2=value2
?name1=&name2=value2
Both these query strings, for param "name1", param->value is
non-NULL and len 0.
Maybe for the first query string, we should set the param->value
as NULL, so that we can differentiate it from the second query where
name1 is in the key-value format but without the value set?
3. Suricata provides conf settings to enable double decoding for path
and query. We do this by hooking into the request line callback.
Do we have any internal support from libhtp for decoding double
encoded characters, without we explicity having to force it?
On Wed, Jun 12, 2013 at 4:26 PM, Victor Julien <victor at inliniac.net> wrote:
> On 06/10/2013 04:06 PM, Anoop Saldanha wrote:
>> We enabled some features here to decode path in query here -
>> https://github.com/inliniac/suricata/commit/d41c762689a08e6814dc93e8bfebeceab97175c3
>>
>> If a query parameter is an uri, should be decode the uri? It's an
>> argument and from the user perspective we don't know how the user
>> treats the query argument internally . So some of the settings wrt
>> decoding a path in a query may not make sense?
>
> I don't think we should decode an uri if it's part of a query parameter
> value.
>
--
-------------------------------
Anoop Saldanha
http://www.poona.me
-------------------------------
More information about the Oisf-devel
mailing list