Development/Hardening-go-Programs.md

+## Hardening go Programs
+
+This page is supposed to help us make our developed software more secure in the sense of making sure we avoid common vulnerabilities or code that is known to produce bugs. By no means, the information available here is supposed to be complete and should be updated/imporved over time. If you stumble upon any _violations_ of these recommendations during reviews or when coding feel free to adjust the code accordingly.
+
+### Recommendations
+
+The information in this section gives an overview of recommendations for go code which are/might be relevant for us and is currently based only on this [article](https://cyber.orijtech.com/cosmos/hardening/). Please add the sources, if any informationen gets added in the future.
+
+#### Low Hanging Fruits
+
+These recommendations are considered to be easy to implement/use in your daily coding routine and easy to find in already existing code.
+
+* Prevent leaks in go routines by passing a context to the function which will get called as a go routine
+  * Additionally when using channels:
+    * Check if it's still open
+    * Example:
+      * <span dir="">`for` `{` `// Otherwise carry on doing the work select { case w, stillOpen := <-jobsCh:` `if !stillOpen { return } do(ctx, w)` `case <-ctx.Done(): return } }`</span>
+* Limit permissions for files/executables created in the running program as much as possible
+  * Example: 0600 seems to be sufficient for config files, 0700 for executables (these only allow user to do things)
+  * Add more permissions if necessary but keep it as strict as possible
+* When using `chan os.Signal` make sure to initialize them as buffered as in the following:
+  * `make(chan os.Signal, 1)`
+* Create maps with make to ensure they are initialized correctly
+  * Example: `m := make(map[any]any)`
+* Salt your passwords even after hashing them before storing them in databases
+
+#### Advanced Recommendations
+
+These recommendations are harder to implement or use or also maybe less relevant, but should be still considered when adding/editing/reviewing code.
+
+* Consider to use [fuzzing](https://go.dev/security/fuzz/) in tests where it can be reasonably applied
+* Check for possible overflow or unwanted values in passed parameters, especially important for type casts to prevent some bugs (probably easiest for integer and other numbers)
+  * Example: Reject and stop further processing by throwing an erorr inside a method in this case: if an int with a value \>=0 is expected but one with a value \<0 is provided.
+* Avoid using tls.Config.InsecureSkipVerify
+  * Use crypto/tls.Config.InsecureSkipVerify instead (which can make testing harder, so implement this as a later step)
+* Iterate on extracted and sorted map keys instead of directly on map iteration
+  * Using this kind of loop _can_ cause issues in specific cases because it is not deterministic:
+    * `for k, v := range m { ... }` 
+  * Instead use this, to have a deterministic behaviour:
+    * `keys := maps.Keys(m) slices.Sort(keys) for _, k := range keys { ... }`
+* Avoid time.Now() which is localized and instead use a consensus aware clock
+  * Reason: it can cause sync issues in specific cases!
+  * No good example yet!
+* Don’t accept arbitrary inputs for memory allocation: set sane bounds checks and avoid arbitrary integer type casts
+  * Range checks can prevent the issue of attacks where the use of memory allocating gets abused, so called “death by a thousand cuts”
+  * Check the example for overflow handling to deal with this issue in the same way 
+
+### Considerations
+
+* Understand the order of package loading in Go ([click here for info](https://cyber.orijtech.com/cosmos/hardening/#fb475aec-7c93-4d1f-82c2-223f3a9f52f6))
+* Checksec seems to be quite good for us already we could consider enabling the 'pie' flag in the go build options to presumably harden our binary, but have to deal with larger binaries. Need to discuss about the consequences about this ([click here for info](https://devdrivensecurity.substack.com/p/hardening-go-programs-1n))
\ No newline at end of file