1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
Design Flaws in doscan
----------------------
Despite its small size, doscan contains several design flaws which are
somewhat hard to address at this point.
* Error reporting is rather poor. The reporting engine in
src/result.{h,cc} has hardly been modified since the switch from C
to C++. A complete rewrite is necessary for more accurate
reporting of errors.
* Scanning modules are harder to write than expected. The
single-threaded, non-blocking I/O design of doscan is certainly
quite performant (as it minimizes context switches), but it's too
hard to write moderately complex protocol modules. The HTTP
client/server code is a bad example. The current interfaces are
also somewhat error-prone (unbounded memory allocation can occur
if the protocol module is not written carefully).
* The connect() rate limiting needs a complete overhaul. It's
likely that we stress the network more than necessary because we
do not adequately distribute connect() calls in time.
And finally, C++ is an unsafe programming language. Buffer overflows
lurk at almost every corner.
|
