Live data from Hacker News

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

github.com

41–50 of 80 posts

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

#41
post #28
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?

Some would argue that if you're testing on a system you can't recreate easily/quickly, you're doing devops wrong.

And I'd agree, but this would be a pretty disproportionate punishment for the crime of doing devops wrong :P

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

#42
post #33

Earlier quoted context omitted.

Bi-directional text is probably another one. All the bidi control characters, especially. Probably really all Unicode control characters in general.

Sure, but there's already a lot of bidi text in the file.

Bah, I only saw mono-directional text. Looking closely I only see one line of with bi-directional text, "הָיְתָהtestالصفحات التّحول"?

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

#43
post #38
post #13

Earlier quoted context omitted.

Thankfully, there are no strings invoking Cthulhu :)

lol! You must be referring to the ICFP contest 2015. http://icfpcontest.org/

I was actually inspired by the concept that lovecraftian horrors can be accessed and interacted with programmatically, prominently featured in Stross's Atrocity Archives: https://en.wikipedia.org/wiki/The_Atrocity_Archives

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

#44
post #33

Earlier quoted context omitted.

Sure, but there's already a lot of bidi text in the file.

Bah, I only saw mono-directional text. Looking closely I only see one line of with bi-directional text, "הָיְתָהtestالصفحات التّحول"?

There are Bidi controller characters in the Trick Unicode. (Doesn't appear in Github rendering, oddly)

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

#46
One fun (and very interesting) string is EICAR[0]. I worked for an antivirus company once and we had the EICAR string for testing but couldn't check it into source control because it triggered the AV software which we dogfooded...

Is it naughty to include it here?

    X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

[0] https://en.wikipedia.org/wiki/EICAR_test_file

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

#47
post #28
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?

Some would argue that if you're testing on a system you can't recreate easily/quickly, you're doing devops wrong.

The problem is not restoring the system, but the time lost in figuring out what caused it without any logs.

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

#48
for anyone testing web sites, I built a chrome extension that makes things like this available in the right-click menu [1] the code is on github, so it can be easily extended [2]

[1] - https://chrome.google.com/webstore/detail/bug-magnet/efhedld...

[2] - https://github.com/gojko/bugmagnet

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

#49
post #28
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?

Some would argue that if you're testing on a system you can't recreate easily/quickly, you're doing devops wrong.

A lot of people do devops wrong... and I don't want to make those people even more scared to test things.

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

#50
post #6

Yeah, I would make the SQL injection and command injections test a little less kinetic =). Using a simple SELECT test, like SELECT @@VERSION, would be a little safer... Edit: Forget to say thanks! This is a pretty cool list.

You want something that modifies so that you can detect that the SQL executed. But an INSERT would be a much friendlier than a DROP TABLE. :)

Not necessarily. If you do a test with good SQL and a second test with SQL Injection and compare the responses that can show SQL Injection exists without having to change the database. This won't work for all SQL injection tests, but I would rather take this approach first.
Post reply on HN