TigahandGitHub
dff4de397e
* feat(config): add -config/-profile config file and profile overlays extend the existing goflags yaml config mechanism (the same one -template already uses) with an explicit -config path and named -profile overlays, instead of adding a second config system. resolveConfigInput unifies -config/-profile/-template into a single flat yaml path for goflags to merge before Parse: unset, it returns "" and goflags falls back to its ambient ~/.config/sif/config.yaml unchanged. a profile overlays its keys onto the file's top-level keys in a go map before handing goflags a flat temp file, so precedence stays explicit cli flag > profile > file default > built-in default via goflags' own DefValue sentinel merge. -config and -template share one config slot and are mutually exclusive. verifies empirically that goflags auto-creates and merges the ambient config file with no explicit SetConfigFilePath call, which this feature depends on. * docs(config): document -config/-profile and drop the dead toml example template-example.toml was unreferenced by any go file and did not match how goflags actually reads config (flat long-name keys, yaml). replace it with config-example.yaml showing the real schema, including a profiles block, and document -config/-profile in the usage/configuration guides and the man page. * fix(config): validate malformed config on the no-profile path resolveConfigInput used to return an explicit -config path unparsed when -profile was not set, so a malformed yaml file skipped validation entirely. goflags then silently discarded the decode error, dropping every real setting in the file with no diagnostic and exit 0, while the same file with -profile already errored cleanly through loadConfigMap. route both branches through one buildFlatConfig that always loads via loadConfigMap and only overlays a profile when one is selected, so a malformed file errors the same way regardless of -profile. * fix(config): let explicit cli flags override config and profile values goflags' own merge (readConfigFile) treats a flag whose current value equals its DefValue as "unset" and applies the config value over it. that makes an explicit cli flag silently lose to the config file or a profile whenever the user happens to pass the flag's own default, e.g. "-timeout 10s" against the built-in 10s default: today the file's 1s wins even though the flag was set explicitly on the command line. the same class of bug hits -threads, -concurrency, -notify-severity, and any profile value on the same merge path. scan the raw args for every flag the user actually passed (long or short alias, space or "=" form) and strip those keys out of the resolved config/ profile map before it ever reaches goflags, so cli precedence holds unconditionally instead of only when the value differs from the default. flagAliasGroups derives the long/short alias groups from the real flag registration (grouping by the shared flag.Value pointer) rather than a second hardcoded name table, so it can't drift from registerFlags. goflags also swallows a type-mismatched config value entirely (discards fl.Value.Set's error); that is a separate, lower-severity gap in the vendored dependency itself and is left alone, noted in a comment.
4.8 KiB
configuration
runtime configuration options for sif.
environment variables
SHODAN_API_KEY
required for shodan lookups.
export SHODAN_API_KEY=your-api-key-here
./sif -u https://example.com -shodan
command line options
timeout
default request timeout is 10 seconds.
# increase for slow targets
./sif -u https://example.com -t 30s
# decrease for fast scans
./sif -u https://example.com -t 5s
threads
default is 10 concurrent threads.
# more threads for faster scanning
./sif -u https://example.com --threads 50
# fewer threads to reduce load
./sif -u https://example.com --threads 5
logging
save output to files:
./sif -u https://example.com -l ./logs
creates timestamped log files in the specified directory.
debug mode
enable verbose logging:
./sif -u https://example.com -d
templates
-template loads a batch of scan settings from a built-in preset or a local yaml file, so a run does not have to pass every flag. see the usage guide for the presets and file format. command-line flags still take precedence over the template.
sif also reads an ambient config at ~/.config/sif/config.yaml (created on first run) keyed by the same flag names. passing -template uses that template as the config for the run instead of the ambient file.
config file and profiles
-config PATH points sif at a yaml config file instead of the ambient ~/.config/sif/config.yaml. its top-level keys are flag long-names, applied as file defaults, the same schema the ambient file uses. see config-example.yaml.
-profile NAME selects a profiles.NAME block from that config file and overlays its keys on top of the top-level defaults before the run starts:
threads: 20
profiles:
quick:
probe: true
dirlist: small
./sif -u https://example.com -config ./config-example.yaml -profile quick
precedence, highest wins: an explicit cli flag, then the selected profile, then the file's top-level defaults, then sif's built-in defaults. selecting a profile that does not exist in the file is a hard error listing the profiles that do. -config and -template are mutually exclusive, since both point sif at the same underlying config slot.
user modules
place custom modules in:
- linux/macos:
~/.config/sif/modules/ - windows:
%LOCALAPPDATA%\sif\modules\
directory structure
~/.config/sif/
├── modules/
│ ├── http/
│ │ └── my-sqli-check.yaml
│ ├── recon/
│ │ └── custom-paths.yaml
│ └── my-module.yaml
modules can be organized in subdirectories or placed directly in the modules folder.
overriding built-in modules
user modules with the same id as built-in modules will override them:
# ~/.config/sif/modules/sqli-error-based.yaml
# this overrides the built-in sqli-error-based module
id: sqli-error-based
info:
name: my custom sqli check
# ...
custom signatures
framework detection (-framework) also loads user-defined detectors from yaml
files, so a framework sif does not ship can be detected without rebuilding:
- linux/macos:
~/.config/sif/signatures/ - windows:
%LOCALAPPDATA%\sif\signatures\
each file defines one detector; place them directly in the directory, as
subdirectories are not scanned. header: true matches a response header name or
value (case-insensitive) instead of the body; the optional version block pulls
a version out of the body.
# ~/.config/sif/signatures/ghost.yaml
name: Ghost
signatures:
- pattern: 'content="Ghost'
weight: 0.6
- pattern: 'X-Ghost-Cache'
weight: 0.4
header: true
version:
regex: 'content="Ghost ([0-9.]+)'
group: 1
a detector reports a match once its matched signature weights sum past half, so
weight your signatures to total about 1.0. a name matching a built-in detector
overrides it and inherits that built-in's version patterns and known cves, the
same as user modules.
performance tuning
fast scans
./sif -u https://example.com \
--threads 50 \
-t 5s \
-dirlist small \
-dnslist small
thorough scans
./sif -u https://example.com \
--threads 10 \
-t 30s \
-dirlist large \
-dnslist large \
-ports full
low-impact scans
reduce load on target:
./sif -u https://example.com \
--threads 2 \
-t 10s
output formats
console (default)
human-readable output with colors and formatting.
json (api mode)
./sif -u https://example.com -api
returns structured json:
{
"url": "https://example.com",
"results": [
{
"id": "sqli-error-based",
"data": {
"findings": [...]
}
}
]
}
log files
./sif -u https://example.com -l ./logs
creates separate log files for each scan type.