Live data from Hacker News

Show HN: Big List of Naughty Strings for testing user-input data

github.com

71–80 of 80 posts

Re: Show HN: Big List of Naughty Strings for testing user-input data

#71
post #51

OT but is there a way to see projects with the most stars on github? This one seems to be skyrocketing. Oh here we go, and lookie who is at the top: https://github.com/trending

https://github.com/stars?direction=desc&sort=stars

Well that is for your account, I meant overall for the system and the trending report does that...

Re: Show HN: Big List of Naughty Strings for testing user-input data

#74

/dev/urandom can also be used as a source of random and unusual input data, as it contains by definition all 256 byte values and 65536 2-byte values, 16M 3-byte values, etc., and should eventually output every possible string.

> and should eventually output every possible string.

"Eventually" being the key word here. Fuzzing with purely random inputs will take eons to actually reveal non-trivial bugs...

Re: Show HN: Big List of Naughty Strings for testing user-input data

#75
post #66
post #19

" # Server Code Injection # # Strings which can cause user to run code on server as a privileged user (c.f. https://news.ycombinator.com/item?id=7665153 ) /dev/null; rm -rf /*; echo " That's a little aggressive for testing no?

Likewise: 1;DROP TABLE users 1'; DROP TABLE users-- Seems a bit hairy to have that in there in case someone tries to run these tests on their prod environment

Why would you test in a prod environment?

Re: Show HN: Big List of Naughty Strings for testing user-input data

#77
post #75
post #66

Earlier quoted context omitted.

Likewise: 1;DROP TABLE users 1'; DROP TABLE users-- Seems a bit hairy to have that in there in case someone tries to run these tests on their prod environment

Why would you test in a prod environment?

Well the sample was testing against twitter (obviously prod).

So someone may test against prod if they didn't really know what these things could do.

Re: Show HN: Big List of Naughty Strings for testing user-input data

#78
post #61

Earlier quoted context omitted.

Aw, Sophos on OS X doesn't think it's a threat.

Without giving too much away, I was sufficiently surprised by that that I downloaded the Sophos for Mac Home Edition. It does recognise it. Here's what I get: http://i.imgur.com/JQzVsQf.png This was picked up by the on-access scanner and a manual scan. The Web Protection doesn't complain about the text in a page (rightly or wrongly). Are you using a centrally managed version (i.e. not Home Edition)?

Interestingly, I found what caused the false-negative. If I used Vim to create the file, it was picked up. If I "echo ...EICAR > text.txt" it doesn't get picked up, at least not immediately!

Re: Show HN: Big List of Naughty Strings for testing user-input data

#79
post #19

" # Server Code Injection # # Strings which can cause user to run code on server as a privileged user (c.f. https://news.ycombinator.com/item?id=7665153 ) /dev/null; rm -rf /*; echo " That's a little aggressive for testing no?

it also won't work as most systems are going to require --no-preserve-root for that to do anything.

Re: Show HN: Big List of Naughty Strings for testing user-input data

#80
post #78

Earlier quoted context omitted.

Without giving too much away, I was sufficiently surprised by that that I downloaded the Sophos for Mac Home Edition. It does recognise it. Here's what I get: http://i.imgur.com/JQzVsQf.png This was picked up by the on-access scanner and a manual scan. The Web Protection doesn't complain about the text in a page (rightly or wrongly). Are you using a centrally managed version (i.e. not Home Edition)?

Interestingly, I found what caused the false-negative. If I used Vim to create the file, it was picked up. If I "echo ...EICAR > text.txt" it doesn't get picked up, at least not immediately!

The on-access scanner intercepts requests to open files, and scans them. Echo just writes to the file and closes it. It doesn't try to open it again once the EICAR string is in there. I'm speculating here, but Vim probably writes the file/buffer, flushes, and then tries to obtain a file handle to it. At that point an on-access scan will occur, and it will find the EICAR string.

A scheduled scan would pick this up eventually.

Post reply on HN