1.15b - Documentation and path mapping changes
- Better documentation of why certain issues are not reported by skipfish. - Another minor tweak to path mapping detection logic.
This commit is contained in:
parent
61ba870458
commit
662a6138f4
|
@ -1,3 +1,10 @@
|
|||
Version 1.15b:
|
||||
--------------
|
||||
|
||||
- Better documentation of why certain issues are not reported by skipfish.
|
||||
|
||||
- Another minor tweak to path mapping detection logic.
|
||||
|
||||
Version 1.14b:
|
||||
--------------
|
||||
|
||||
|
|
16
README
16
README
|
@ -172,6 +172,22 @@ Along with a list of identified issues, skipfish also provides summary
|
|||
overviews of document types and issue types found; and an interactive sitemap,
|
||||
with nodes discovered through brute-force denoted in a distinctive way.
|
||||
|
||||
NOTE: As a conscious design decision, skipfish will not redundantly complain
|
||||
about highly non-specific issues, including but not limited to:
|
||||
|
||||
* Non-`httponly` cookies,
|
||||
* Non-HTTPS or `autocomplete`-enabled forms,
|
||||
* HTML comments detected on a page,
|
||||
* Filesystem path disclosure in error messages,
|
||||
* Server of framework version disclosure,
|
||||
* Mere presence of certain technologies, such as WebDAV.
|
||||
|
||||
Most of these aspects are easy to inspect in a report if so desired - for
|
||||
example, all the HTML forms are listed separately, so are new cookies or
|
||||
interesting HTTP headers - and the expectation is that the auditor may opt to
|
||||
make certain design recommendations based on this data where appropriate. That
|
||||
said, these occurrences are not highlighted as a specific security flaw.
|
||||
|
||||
-----------------------------------------------------------
|
||||
3. All right, I want to try it out. What do I need to know?
|
||||
-----------------------------------------------------------
|
||||
|
|
2
config.h
2
config.h
|
@ -23,7 +23,7 @@
|
|||
#ifndef _HAVE_CONFIG_H
|
||||
#define _HAVE_CONFIG_H
|
||||
|
||||
#define VERSION "1.14b"
|
||||
#define VERSION "1.15b"
|
||||
|
||||
#define USE_COLOR 1 /* Use terminal colors */
|
||||
|
||||
|
|
14
crawler.c
14
crawler.c
|
@ -2731,7 +2731,7 @@ u8 fetch_unknown_callback(struct http_request* req, struct http_response* res) {
|
|||
response, assume file. This is a workaround for some really
|
||||
quirky architectures. */
|
||||
|
||||
if (par && res->pay_len && res->code >= 200 && res->code < 400 &&
|
||||
if (par && res->pay_len && res->code == 200 &&
|
||||
same_page(&par->unk_sig, &res->sig)) {
|
||||
|
||||
req->pivot->type = PIVOT_FILE;
|
||||
|
@ -2739,6 +2739,18 @@ u8 fetch_unknown_callback(struct http_request* req, struct http_response* res) {
|
|||
|
||||
}
|
||||
|
||||
/* Another workaround for quirky frameworks: identical signature
|
||||
as parent's both probes, and 3xx code. */
|
||||
|
||||
if (par && res->code >= 300 && res->code < 400 &&
|
||||
same_page(&par->unk_sig, &res->sig) &&
|
||||
same_page(&par->res->sig, &res->sig)) {
|
||||
|
||||
req->pivot->type = PIVOT_FILE;
|
||||
return fetch_file_callback(req, res);
|
||||
|
||||
}
|
||||
|
||||
/* Schedule a request to settle the type of this pivot point. */
|
||||
|
||||
n = req_copy(req, req->pivot, 1);
|
||||
|
|
Loading…
Reference in New Issue