Insecure fn

language design
1

Hi, i request that feature because example let's have

fn generate_img_src(url: String) -> String {
    format!(r#"<img src="{}" />"#, url)
}

that function is insecure because vulnerable to XSS, i propose something like

#[insecure]
fn generate_img_src(url: String) -> String {
    format!(r#"<img src="{}" />"#, url)
}

unlike unsafe, that is like #[deprecated] however, the function itself is not deprecated and internally with trusted input required, however if marked insecure, it warns you about it, to do so, you can do

static URL: &str = "https://imageserver.com/cat.png";

#[allow(insecure)]
fn generate_cat_img_html() {
   let a = generate_img_src(String::from(URL));
   a
}

because that is an internal func now that is safe, that supresses the compiler warning

warning: use of insecure function `generate_img_src`

by default will be

#[warn(insecure)]

like deprecated, but however for insecure function, the motivation is to dev minimize using insecure func and that is good, makes rust even more good language not just memory safe also offer logic safety, for insecure functions for devs use proper safe ways

2

Why not a TrustedString or some similar wrapper? That's what systems that need to work with a mix of trusted and untrusted data often end up with. E.g. the Trusted Types webapis

5 Likes
3

but by example weak crypto rng, that just an example, TrustedString cannot mitigate weak crypto and other buisness logic issues, #[insecure] will do if the dev mark in their crate a func is insecure to call

4

With cryptography "insecure" gets complicated. Is 4096bit RSA insecure? Well, depends on how much progress you're expecting quantum computers or integer factoring to make in the next few years.

2 Likes
5

What does it mean for a function to be "insecure"? That depends on the context and the passed arguments. What one program considers insecure could be expected behavior for another program. I don't think having a single fixed insecure marker would help much. It would rather either be very noisy or miss things or both.

Some libraries wrap potentally untrusted values in a newtype or require you to pass in a marker value to functions with a side-effect that you have to be careful about.

6 Likes
6

Echoing @bjorn3, "insecure" is not an absolute descriptor. It only has meaning within the context of a threat model. What is suitable for "backyard projects" may be insecure for FIPS-requiring contexts. That may in turn be unsuitable for NSA-level security procedures.

2 Likes
7

The way cryptography works, it is entirely possible (and maybe even likely) for someone who don't understand cryptography to put together a bunch of individually secure components, and create an overall insecure system.

1 Like
8

Why not just fix the bug instead of marking the function with an attribute?

use html_escape::encode_double_quoted_attribute;

fn generate_img_src(url: &str) -> String {
    format!(r#"<img src="{}" />"#, encode_double_quoted_attribute(url))
}
4 Likes