Sensitive data in stacktrace

tim2CF · January 17, 2019, 11:09am

Let’s say we have a module like

defmodule Foo do
  @salt Application.get_env(:foo, :salt, [])
  def hash(password) do
    try do
      {:ok, md5(password, @salt)}
    rescue 
      e -> {:error, {e, __STACKTRACE__}}
    end
  end
  defp md5(password, salt = [_ | _]) do
    Enum.reduce(salt, password, &:erlang.md5(&2<>&1))
  end
end

And when we call &hash/1 function it returns error

iex(19)> Foo.hash "123"
{:error,
 {%FunctionClauseError{
    args: nil,
    arity: 2,
    clauses: nil,
    function: :md5,
    kind: nil,
    module: Foo
  },
  [
    {Foo, :md5, ["123", []], [file: 'iex', line: 27]},
    {Foo, :hash, 1, [file: 'iex', line: 22]},
    {:erl_eval, :do_apply, 6, [file: 'erl_eval.erl', line: 677]},
    {:elixir, :eval_forms, 4, [file: 'src/elixir.erl', line: 265]},
    {IEx.Evaluator, :handle_eval, 5, [file: 'lib/iex/evaluator.ex', line: 249]},
    {IEx.Evaluator, :do_eval, 3, [file: 'lib/iex/evaluator.ex', line: 229]},
    {IEx.Evaluator, :eval, 3, [file: 'lib/iex/evaluator.ex', line: 207]},
    {IEx.Evaluator, :loop, 1, [file: 'lib/iex/evaluator.ex', line: 94]}
  ]}}

And we want to put this stacktrace to Logger (let’s say for easier debugging)
But we see, what stacktrace can contain sensitive data (in example is password = “123”)
Of course we can remove all arguments from stacktrace manually, but in most cases arguments are useful
Maybe there is already implemented solution to remove some arguments of some functions from stacktrace by marking them in module definition somehow?

It would be nice to say somehow that n-th argument of foo function in module Bar is sensitive and should be excluded from stacktrace

sfusato · January 17, 2019, 11:26am

There is ‘Custom struct inspections’ that was just released with Elixir 1.8:

github.com

elixir-lang/elixir/blob/v1.8/CHANGELOG.md

# Changelog for Elixir v1.8

Elixir v1.8 comes with many improvements at the infrastructure level, improving compilation time, speeding up common patterns, and adding features around introspection of the system.

## Custom struct inspections

Elixir now provides a derivable implementation of the `Inspect` protocol. In a nutshell, this means it is really easy to filter data from your data structures whenever they are inspected. For example, imagine you have a user struct with security and privacy sensitive information:

```elixir
defmodule User do
  defstruct [:id, :name, :age, :email, :encrypted_password]
end
```

By default, if you inspect a user via `inspect(user)`, it will include all fields. This can cause fields such as `:email` and `:encrypted_password` to appear in logs, error reports, etc. You could always define a custom implementation of the `Inspect` protocol for such cases but Elixir v1.8 makes it simpler by allowing you to derive the `Inspect` protocol:

```elixir
defmodule User do
  @derive {Inspect, only: [:id, :name, :age]}
  defstruct [:id, :name, :age, :email, :encrypted_password]

This file has been truncated. show original

Maybe return just the tail of the stack trace and at an upper-level inspect your struct with the returned stack trace. This would obfuscate the password field or whatever you set to hide from your struct.

josevalim · January 17, 2019, 12:11pm

Here is what Plug.Crypto does regarding the stacktrace: https://github.com/elixir-plug/plug_crypto/blob/76a595f26529cd550f32166c3288358e1785fb1f/lib/plug/crypto/key_generator.ex#L47

zazaian · October 11, 2019, 6:17pm

@sfusato’s response is very good, though it seems that in some instances you’d want to expressly name the excluded struct parameters, rather than list all of the unexcluded ones.

The Inspect protocol actually allows you to name the struct attributes that are excluded from inspection, which is cleaner for circumstances in which most of a struct’s attributes are not private or secret. Here’s an example:

defmodule CustomRequest do
  @derive {Inspect, except: [:password]}
  defstruct [:name, :email, :password]
end

If you had a myriad of secret attributes within a single struct though, using only is probably cleaner and safer, as adding additional secret attributes would not require you to also add them for exclusion:

defmodule CustomRequest do
  @derive {Inspect, only: [:name, :email]}
  defstruct [
    :name,
    :email,
    :password,
    :secret_token,
    :secret_id
  ]
end

Please note that the @derive call does have to be declared above the defstruct keyword as indicated in the Inspect docs, as shown above.