Looking for the Secure Coding Guide

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Looking for the Secure Coding Guide

eric-2
I reviewed the docs page on the Erlang site (http://www.erlang.org/docs)
and searched elsewhere and cannot find a secure coding guide (yes, I did
find some secure coding recommendations - like "do not program
defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11,
but didn't find the advice compelling). So, does a secure coding guide
exist exist and if so, could I get a copy of it? If one does not exist,
is there something in development and when will it be available?

Also, does anyone know if there is any type of static code assessment
tool that exists to test for or verify adherence to the secure coding
guide practices (again, presuming one exists)?

Thanks for your help.

Eric

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Looking for the Secure Coding Guide

Juan Martín Guillén
Hi Eric,

I am sure you would find these links useful:




Juan Martín.


El viernes, 1 de marzo de 2019 13:13:03 ART, [hidden email] <[hidden email]> escribió:


I reviewed the docs page on the Erlang site (http://www.erlang.org/docs)
and searched elsewhere and cannot find a secure coding guide (yes, I did
find some secure coding recommendations - like "do not program
but didn't find the advice compelling). So, does a secure coding guide
exist exist and if so, could I get a copy of it? If one does not exist,
is there something in development and when will it be available?

Also, does anyone know if there is any type of static code assessment
tool that exists to test for or verify adherence to the secure coding
guide practices (again, presuming one exists)?

Thanks for your help.

Eric

_______________________________________________
erlang-questions mailing list

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Looking for the Secure Coding Guide

eric-2
Hi Juan,

Thanks for the links - I guess I'm trying to find something that
operationalizes specifically for Erlang the OWASP guidance found here
(Yes, I'm aware that not all of this applies to Erlang, but where it
does apply, is there guidance around how it should be operationalized in
Erlang development?) -
https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf

The documents you linked to touch on security while focusing on
operational results (in my opinion) as did the document I linked to
below; however, they don't focus on security. I'm looking for something
that focuses specifically on security regardless of whether it makes
coding easier or more difficult. In other words,

Regarding Dialyzer, I'm not sure that Dialyzer would call out something
that is syntactically correct; however, unadvisable as it introduces
risk to the information. It is syntactically correct to receive input
without any input validation (this would not throw an error in the
application); however, would Dialyzer provide an alert that input
validation was not present (just a for instance)?

Thanks again,
Eric Svetcov

On 01.03.2019 10:30, Juan Martín Guillén wrote:

> Hi Eric,
>
> I am sure you would find these links useful:
>
> https://github.com/inaka/erlang_guidelines
>
> http://erlang.org/doc/man/dialyzer.html
>
> Juan Martín.
>
> El viernes, 1 de marzo de 2019 13:13:03 ART, [hidden email]
> <[hidden email]> escribió:
>
> I reviewed the docs page on the Erlang site
> (http://www.erlang.org/docs)
>
> and searched elsewhere and cannot find a secure coding guide (yes, I
> did
>
> find some secure coding recommendations - like "do not program
>
> defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11,
> [1]
>
> but didn't find the advice compelling). So, does a secure coding guide
>
>
> exist exist and if so, could I get a copy of it? If one does not
> exist,
>
> is there something in development and when will it be available?
>
> Also, does anyone know if there is any type of static code assessment
>
> tool that exists to test for or verify adherence to the secure coding
>
> guide practices (again, presuming one exists)?
>
> Thanks for your help.
>
> Eric
>
> _______________________________________________
>
> erlang-questions mailing list
>
> [hidden email]
>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> Links:
> ------
> [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11,
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Looking for the Secure Coding Guide

Juan Martín Guillén
Hi Eric,

Now I see what you are looking for.

You are right; Dialyzer, or any similar tool, would make a semantic static analysis on the source code and won't complain about input validations or that sort of things.

A tool that makes a security analysis similar to the link you sent would be something very different from that.

In fact, it would be something a software tool could only do partially IMHO.

Anyway, I don't know about any tool that does what you are needing, I'm sorry.

Juan Martín.





El viernes, 1 de marzo de 2019 14:04:31 ART, [hidden email] <[hidden email]> escribió:


Hi Juan,

Thanks for the links - I guess I'm trying to find something that
operationalizes specifically for Erlang the OWASP guidance found here
(Yes, I'm aware that not all of this applies to Erlang, but where it
does apply, is there guidance around how it should be operationalized in
Erlang development?) -
https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf

The documents you linked to touch on security while focusing on
operational results (in my opinion) as did the document I linked to
below; however, they don't focus on security. I'm looking for something
that focuses specifically on security regardless of whether it makes
coding easier or more difficult. In other words,

Regarding Dialyzer, I'm not sure that Dialyzer would call out something
that is syntactically correct; however, unadvisable as it introduces
risk to the information. It is syntactically correct to receive input
without any input validation (this would not throw an error in the
application); however, would Dialyzer provide an alert that input
validation was not present (just a for instance)?

Thanks again,
Eric Svetcov

On 01.03.2019 10:30, Juan Martín Guillén wrote:

> Hi Eric,
>
> I am sure you would find these links useful:
>
> https://github.com/inaka/erlang_guidelines
>
> http://erlang.org/doc/man/dialyzer.html
>
> Juan Martín.
>
> El viernes, 1 de marzo de 2019 13:13:03 ART, [hidden email]
> <[hidden email]> escribió:
>
> I reviewed the docs page on the Erlang site
> (http://www.erlang.org/docs)
>
> and searched elsewhere and cannot find a secure coding guide (yes, I
> did
>
> find some secure coding recommendations - like "do not program
>
> defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11,
> [1]
>
> but didn't find the advice compelling). So, does a secure coding guide
>
>
> exist exist and if so, could I get a copy of it? If one does not
> exist,
>
> is there something in development and when will it be available?
>
> Also, does anyone know if there is any type of static code assessment
>
> tool that exists to test for or verify adherence to the secure coding
>
> guide practices (again, presuming one exists)?
>
> Thanks for your help.
>
> Eric
>
> _______________________________________________
>
> erlang-questions mailing list
>
> [hidden email]
>
> http://erlang.org/mailman/listinfo/erlang-questions

>
>
> Links:
> ------
> [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11,

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Looking for the Secure Coding Guide

eric-2
Hi Juan,

Thanks again for your response. I agree that no static code analysis
tool is perfect. Anything that can partially mitigate a risk is better
than no mitigation at all. Other than PEST and Dialyzer, I'm not finding
anything specific for Erlang. I will see if there is anything at RSA
next week (I'm not hopeful).

Regarding a document for secure coding techniques that addresses much of
what is in the OWASP guidance would be helpful. I haven't found anything
around that yet. Just the documents you mentioned below as well as a few
others have little bits of security, but nothing comprehensive.

Thanks again for your help. Knowing that something isn't available is
almost as good as having the document. At least I can now spend time
figuring out how to address this and not try to look for something that
doesn't exist.

Thanks this has been helpful,
Eric Svetcov

On 01.03.2019 11:46, Juan Martín Guillén wrote:

> Hi Eric,
>
> Now I see what you are looking for.
>
> You are right; Dialyzer, or any similar tool, would make a semantic
> static analysis on the source code and won't complain about input
> validations or that sort of things.
>
> A tool that makes a security analysis similar to the link you sent
> would be something very different from that.
>
> In fact, it would be something a software tool could only do partially
> IMHO.
>
> Anyway, I don't know about any tool that does what you are needing,
> I'm sorry.
>
> Juan Martín.
>
> El viernes, 1 de marzo de 2019 14:04:31 ART, [hidden email]
> <[hidden email]> escribió:
>
> Hi Juan,
>
> Thanks for the links - I guess I'm trying to find something that
> operationalizes specifically for Erlang the OWASP guidance found here
> (Yes, I'm aware that not all of this applies to Erlang, but where it
> does apply, is there guidance around how it should be operationalized
> in
> Erlang development?) -
> https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf
>
> The documents you linked to touch on security while focusing on
> operational results (in my opinion) as did the document I linked to
> below; however, they don't focus on security. I'm looking for
> something
> that focuses specifically on security regardless of whether it makes
> coding easier or more difficult. In other words,
>
> Regarding Dialyzer, I'm not sure that Dialyzer would call out
> something
> that is syntactically correct; however, unadvisable as it introduces
> risk to the information. It is syntactically correct to receive input
> without any input validation (this would not throw an error in the
> application); however, would Dialyzer provide an alert that input
> validation was not present (just a for instance)?
>
> Thanks again,
> Eric Svetcov
>
> On 01.03.2019 10:30, Juan Martín Guillén wrote:
>> Hi Eric,
>>
>> I am sure you would find these links useful:
>>
>> https://github.com/inaka/erlang_guidelines
>>
>> http://erlang.org/doc/man/dialyzer.html
>>
>> Juan Martín.
>>
>> El viernes, 1 de marzo de 2019 13:13:03 ART, [hidden email]
>> <[hidden email]> escribió:
>>
>> I reviewed the docs page on the Erlang site
>> (http://www.erlang.org/docs)
>>
>> and searched elsewhere and cannot find a secure coding guide (yes, I
>> did
>>
>> find some secure coding recommendations - like "do not program
>>
>> defensively" -
> http://www.erlang.se/doc/programming_rules.shtml#HDR11,
>> [1]
>>
>> but didn't find the advice compelling). So, does a secure coding
> guide
>>
>>
>> exist exist and if so, could I get a copy of it? If one does not
>> exist,
>>
>> is there something in development and when will it be available?
>>
>> Also, does anyone know if there is any type of static code
> assessment
>>
>> tool that exists to test for or verify adherence to the secure
> coding
>>
>> guide practices (again, presuming one exists)?
>>
>> Thanks for your help.
>>
>> Eric
>>
>> _______________________________________________
>>
>> erlang-questions mailing list
>>
>> [hidden email]
>>
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> Links:
>> ------
>> [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11,
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Looking for the Secure Coding Guide

Bob Gustafson-2
I was reading the article
"https://spectrum.ieee.org/computing/software/mayhem-the-machine-that-finds-software-vulnerabilities-then-patches-them"
when your email came up.

The article talks about the prize winner in the DARPA Cyber Grand
Challenge of 2016. They won $2m for their automated bug finder and
patcher. 6 other challengers did pretty well too.

Perhaps it was not written in Erlang and perhaps the challenge problems
were not so asynchronous, but it is a good story and represents a
milestone in automated bug finding. No source code necessary.

Bob G

On 3/1/19 12:14 PM, [hidden email] wrote:

> Hi Juan,
>
> Thanks again for your response. I agree that no static code analysis
> tool is perfect. Anything that can partially mitigate a risk is better
> than no mitigation at all. Other than PEST and Dialyzer, I'm not
> finding anything specific for Erlang. I will see if there is anything
> at RSA next week (I'm not hopeful).
>
> Regarding a document for secure coding techniques that addresses much
> of what is in the OWASP guidance would be helpful. I haven't found
> anything around that yet. Just the documents you mentioned below as
> well as a few others have little bits of security, but nothing
> comprehensive.
>
> Thanks again for your help. Knowing that something isn't available is
> almost as good as having the document. At least I can now spend time
> figuring out how to address this and not try to look for something
> that doesn't exist.
>
> Thanks this has been helpful,
> Eric Svetcov
>
> On 01.03.2019 11:46, Juan Martín Guillén wrote:
>> Hi Eric,
>>
>> Now I see what you are looking for.
>>
>> You are right; Dialyzer, or any similar tool, would make a semantic
>> static analysis on the source code and won't complain about input
>> validations or that sort of things.
>>
>> A tool that makes a security analysis similar to the link you sent
>> would be something very different from that.
>>
>> In fact, it would be something a software tool could only do partially
>> IMHO.
>>
>> Anyway, I don't know about any tool that does what you are needing,
>> I'm sorry.
>>
>> Juan Martín.
>>
>> El viernes, 1 de marzo de 2019 14:04:31 ART, [hidden email]
>> <[hidden email]> escribió:
>>
>> Hi Juan,
>>
>> Thanks for the links - I guess I'm trying to find something that
>> operationalizes specifically for Erlang the OWASP guidance found here
>> (Yes, I'm aware that not all of this applies to Erlang, but where it
>> does apply, is there guidance around how it should be operationalized
>> in
>> Erlang development?) -
>> https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf
>>
>> The documents you linked to touch on security while focusing on
>> operational results (in my opinion) as did the document I linked to
>> below; however, they don't focus on security. I'm looking for
>> something
>> that focuses specifically on security regardless of whether it makes
>> coding easier or more difficult. In other words,
>>
>> Regarding Dialyzer, I'm not sure that Dialyzer would call out
>> something
>> that is syntactically correct; however, unadvisable as it introduces
>> risk to the information. It is syntactically correct to receive input
>> without any input validation (this would not throw an error in the
>> application); however, would Dialyzer provide an alert that input
>> validation was not present (just a for instance)?
>>
>> Thanks again,
>> Eric Svetcov
>>
>> On 01.03.2019 10:30, Juan Martín Guillén wrote:
>>> Hi Eric,
>>>
>>> I am sure you would find these links useful:
>>>
>>> https://github.com/inaka/erlang_guidelines
>>>
>>> http://erlang.org/doc/man/dialyzer.html
>>>
>>> Juan Martín.
>>>
>>> El viernes, 1 de marzo de 2019 13:13:03 ART, [hidden email]
>>> <[hidden email]> escribió:
>>>
>>> I reviewed the docs page on the Erlang site
>>> (http://www.erlang.org/docs)
>>>
>>> and searched elsewhere and cannot find a secure coding guide (yes, I
>>> did
>>>
>>> find some secure coding recommendations - like "do not program
>>>
>>> defensively" -
>> http://www.erlang.se/doc/programming_rules.shtml#HDR11,
>>> [1]
>>>
>>> but didn't find the advice compelling). So, does a secure coding
>> guide
>>>
>>>
>>> exist exist and if so, could I get a copy of it? If one does not
>>> exist,
>>>
>>> is there something in development and when will it be available?
>>>
>>> Also, does anyone know if there is any type of static code
>> assessment
>>>
>>> tool that exists to test for or verify adherence to the secure
>> coding
>>>
>>> guide practices (again, presuming one exists)?
>>>
>>> Thanks for your help.
>>>
>>> Eric
>>>
>>> _______________________________________________
>>>
>>> erlang-questions mailing list
>>>
>>> [hidden email]
>>>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11,
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Looking for the Secure Coding Guide

Jesper Louis Andersen-2
In reply to this post by eric-2
 (yes, I did
find some secure coding recommendations - like "do not program
defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11,
but didn't find the advice compelling). So, does a secure coding guide
exist exist and if so, could I get a copy of it? If one does not exist,
is there something in development and when will it be available?


While I do recognize we should have a commented version of the OWASP guide in the view of Erlang, and other functional programming languages such as Haskell or Ocaml, the above requires some elaboration as to why it is a guideline.

There are two kinds of input validation in a system for a given function. One is when you have an untrusted source (colloquially known as "the enemy"), the other is when the source is trusted. For the case where the enemy provides data, it should usually be validated with a function looking something like:

-spec validate(Input :: term()) -> {ok, Canonicalized :: term()} | {error, validation}.

This also generally holds true for library design. An application boundary should generally behave somewhat nicely and be able to return errors as values so one can match on them and act accordingly. The rule is that you should punt decisions to the caller of the library, though it does have its exceptions.

However, this is not what the coding guidelines suggest. They pertain to the case of trusted input. In that case, writing protective routines (i.e., defensive code), is usually a mistake in an Erlang system. There is a supervision tree ready to handle this problem if it occurs, and you cannot always fully reflect on each and every possible failure scenario. In fact, trying to mitigate a failure you have not seen in the wild might introduce bugs into the program when it does happen. So defensive code is not a priori a safer option. For trusted sources, it is better to program for the happy path only, and let the errors be logged so they can be handled properly by rewiring of code.

In general, catching all mistakes, trying to mitigate them, and then propagate the error upwards in the call stack is not always a desirable thing. You might not have thought about the particular failure scenario, so it is impossible to mitigate the error before having seen it in the wild. Or you might have assumed that the particular scenario never occurs in practice, in which case the error report is a subtle hint and teaching moment. I often hedge by leaving out some error handling early on, and then provoke the error cases to install the correct handling for the ones that do occur in the real world.

There are some reasons this approach is good:

* Writing for the happy path first allows a much faster time-to-market for a given feature. Some languages force you to envision a lot of defensive additional code before the code is marketable. And as laid out above, that code is rarely executed. Hence, if it contains a bug, you might not know early on.

* If an error occur in the production system, you don't have to handle the error immediately if it rare in occurrence. By construction, a crashing process cannot tie up resources in the system (caveats: ETS, disk storage resources, etc). So you can often leave the error in there until the next service window or deploy. This is particularly strong in the modern world where people continuously deploy code, because you can deploy code and then hotfix the code for the missing corner cases subsequently. This leads to a much faster development cycle overall.

* In a concurrent system, there are certain failure scenarios you might want to detect rather than handle. Detection is often far easier than properly mitigating. So if the occurrence is rare, you can just restart the program and try again.

Finally, there are some overarching security considerations:

* The atom table is limited to about a million atoms. Do not let the enemy create arbitrary atoms (see: e.g., erlang:binary_to_existing_atom(..) for a mitigation technique).
* ETS is not garbage collected, so make sure to clean up. Having a janitor process doing the cleanup and using the concept of monitors to manage the lifetime of other processes storing data in ETS can help a lot.
* The security boundary is the distributed erlang cluster, not an individual node. Once a node is breached, the whole cluster is lost.
* You can mark processes as containing sensitive information, which makes them unable to be inspected by accident by an operator. This is useful if a process contains the current table of law enforcement wiretaps. There are ways around it, but the idea is that you don't accidentally stumble into information that is sensitive.
* The gen_server callback Module:format_status(..) can be used to devour password information in error logs.
* Erlang is a generally memory safe language, so many errors pertaining to bounds checks are not possible. Something like Heartbleed cannot occur, though something like the Bleichenbacher attacks can.
* However do put sensible resource limits on enemies. Don't let them create a binary of 2 gigabyte of size in memory. Load regulate heavy-weight computation in the node and only allow a limited number of those processes.
* Integer overflow/underflow doesn't occur in the language since integers have arbitrary size. But when writing them out into a fixed size integer, care must be taken as it will wrap around there.
* And finally, do not use the dynamic features of the system to let the enemy execute arbitrary code on your end.


--
J.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions