Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brainfuck beware: JavaScript is after you (2012)

patriciopalladino.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Brainfuck beware: JavaScript is after you (2012)

#21

Post by InclinedPlane »

nirmel wrote: post #8

I am not a programmer so this is part curiosity and part criticism. Why do programmers seem to enjoy creating programs that satisfy some syntactical constraint? Is it a fun mental exercise, or or can you just admit that you're showing off on something that really does not matter?

Doesn't matter? There are still lots of places that try to filter user submitted html and javascript to "sanitize" it. And a lot of those filters are blacklist based rather than whitelist. But here we have an example of how it's possible to create any javascript program with purely non alpha-numeric input. I can guarantee you that such a result is immediately applicable to a lot of places around the web. It constitutes an attack vector making it possible to execute arbitrary javascript code in areas where that is allegedly blocked. Exactly how much of an impact that vector has is currently unknown, and hopefully not very large because many devs have realized the futility of trying to filter such things.

However, if there were a magic wand that you could wave which would show the maximum impact of a particular vulnerability and identify all of the sites in the world which were vulnerable and notified all of the site owners instantly with a full report I can guarantee you that there would be a lot of people out there with some sleepless nights and a lot of emergency work ahead of them.

Re: Brainfuck beware: JavaScript is after you (2012)

#22

Post by VMG »

Pitarou wrote: post #7

Yet another example of the horrible mess unprincipled automatic type conversion causes. What prevents language designers from avoiding all these lurking bugs with a generic type-conversion operator? E.g. here's how it might look in a Python-like language: >>> x = 1 >>> y = "2" >>> print(x + cast(y)) 3 >>> print(cast(x) + y) "12" >>> print(cast(x) + cast(y)) Exception: ambiguous type

> Yet another example of the horrible mess unprincipled automatic type conversion causes.

I think you can abuse nearly every language to write crazy code in one way or other.

Re: Brainfuck beware: JavaScript is after you (2012)

#23

Post by [deleted] »

Pitarou wrote: post #7

Yet another example of the horrible mess unprincipled automatic type conversion causes. What prevents language designers from avoiding all these lurking bugs with a generic type-conversion operator? E.g. here's how it might look in a Python-like language: >>> x = 1 >>> y = "2" >>> print(x + cast(y)) 3 >>> print(cast(x) + y) "12" >>> print(cast(x) + cast(y)) Exception: ambiguous type

[deleted]

Re: Brainfuck beware: JavaScript is after you (2012)

#24

Post by CmonDev »

VMG wrote: post #22
Pitarou wrote: post #7

Yet another example of the horrible mess unprincipled automatic type conversion causes. What prevents language designers from avoiding all these lurking bugs with a generic type-conversion operator? E.g. here's how it might look in a Python-like language: >>> x = 1 >>> y = "2" >>> print(x + cast(y)) 3 >>> print(cast(x) + y) "12" >>> print(cast(x) + cast(y)) Exception: ambiguous type

> Yet another example of the horrible mess unprincipled automatic type conversion causes. I think you can abuse nearly every language to write crazy code in one way or other.

In some dynamic weakly-typed languages you don't even need to try that hard to achieve the abuse.

Re: Brainfuck beware: JavaScript is after you (2012)

#25

Post by martin-adams »

nirmel wrote: post #8

I am not a programmer so this is part curiosity and part criticism. Why do programmers seem to enjoy creating programs that satisfy some syntactical constraint? Is it a fun mental exercise, or or can you just admit that you're showing off on something that really does not matter?

I'd say it must be a fun mental exercise. While constraints in a language aren't 'fun' for me, choreography of the CPU (i.e the way the program is architected, written and executed), is.

Compare it to art where an artist only uses a pencil, or limited colour pallet, or limited materials.

Or even art from just a single, constant weighted line: http://www.ignant.de/2013/08/12/one-line-drawing/

There are other benefits to this program in general, one in the area of security and exploring the options for different attack vectors.

Re: Brainfuck beware: JavaScript is after you (2012)

#26

Post by xxs »

alcuadrado wrote: post #18
zatkin wrote: post #6

I'm curious on what the performance implications are. If I have some JavaScript on a webpage that I want to "obfuscate", would using this accomplish the task?

The performance seriously decreases. I haven't measure how much, but I guess it'd only work for very very small scripts.

once the eval() invocation is complete and the code generated/compiled the performance should be the same as the code normally written. Basically it's only compiler from []{}!+ to javascript.

Re: Brainfuck beware: JavaScript is after you (2012)

#27

Post by Pitarou »

anonymoushn wrote: post #15
Pitarou wrote: post #7

Yet another example of the horrible mess unprincipled automatic type conversion causes. What prevents language designers from avoiding all these lurking bugs with a generic type-conversion operator? E.g. here's how it might look in a Python-like language: >>> x = 1 >>> y = "2" >>> print(x + cast(y)) 3 >>> print(cast(x) + y) "12" >>> print(cast(x) + cast(y)) Exception: ambiguous type

Why is this preferable to a set of functions that return a particular type? Most uses of such a cast function would be something like cast(unknown_type) known_type The programmer could just write tostring or tonumber instead of cast, if the type of the other operand is known >_>

Automatic type casting remains popular because it reduces the syntactic and cognitive overhead. I'm suggesting that a better solution would be to retain explicit casting, but minimise the overheads.

So, to take things a step further, lets use, say, the $ operator for casting. Then we have:

    >>> x = 1
    >>> y = "2"
    >>> print($x + y)
    3
    >>> print(x + $y)
    "12"
    >>> print($x + $y)
    CastError: ...
What do you think?

Re: Brainfuck beware: JavaScript is after you (2012)

#29

Post by calibwam »

xxs wrote: post #26
alcuadrado wrote: post #18

Earlier quoted context omitted.

The performance seriously decreases. I haven't measure how much, but I guess it'd only work for very very small scripts.

once the eval() invocation is complete and the code generated/compiled the performance should be the same as the code normally written. Basically it's only compiler from []{}!+ to javascript.

However, your js files would get really big, and download latency could actually be a performance drop.

Re: Brainfuck beware: JavaScript is after you (2012)

#30

Post by mateuszf »

Pitarou wrote: post #27
anonymoushn wrote: post #15

Earlier quoted context omitted.

Why is this preferable to a set of functions that return a particular type? Most uses of such a cast function would be something like cast(unknown_type) known_type The programmer could just write tostring or tonumber instead of cast, if the type of the other operand is known >_>

Automatic type casting remains popular because it reduces the syntactic and cognitive overhead. I'm suggesting that a better solution would be to retain explicit casting, but minimise the overheads. So, to take things a step further, lets use, say, the $ operator for casting. Then we have: >>> x = 1 >>> y = "2" >>> print($x + y) 3 >>> print(x + $y) "12" >>> print($x + $y) CastError: ... What do you think?

Python example with str and int are IMHO much better. They require only little more typing, but are very readable and explicit.
Post reply on HN