Tag Info

New answers tagged

0

If your on Mac or Linux there is a little program on Github called FluxFonts which may do what you need. According to the Read Me file: Fluxfonts – a continual font generator for increased privacy ... New fonts are generated by the daemon every 2 to 40 minutes. Fonts are generated at random times in this time window. However, they are generated more ...


4

Chrome has default protection against Reflective XSS attacks. In Chrome there is a flag with which you can start the browser. If you start the browser with this flag, you can do what you want: --disable-web-security


1

They are not necessarily exclusive. They take advantage of different weaknesses. If you have the ability to do a "traditional" XSS through a reflected attack, then you likely wouldn't need to attempt a dom-based attack because you can inject any code you want before the page loads. In your examples, its not quite clear if you are differentiating the root ...


1

I observed that certain attacks could be both DOM-based and Reflected XSS No. What you list are the same payloads for both DOM based and reflected XSS (both attacks are often exploited in similar ways). But what happens underneath that is still either DOM based XSS or reflected XSS (well, or stored XSS). It's never both. The names for the different ...


1

The risks are more on the client end of things than your server side. What I mean by that is as a consumer I do not want my data going to your server for "processing" which then gets sent over to stripe/wepay. I dont know how you're transmitting the data or whether or not you're not storing it the way you say you are. Also from the consumer side of things if ...


0

You've nailed it. It seems that the way to go is to NOT use the AngularJS method, and instead to break the model and to use the pure javascript redirect to refresh the site onto the Login page. This does seem to clear the network requests. Is this the recommended method? You're best assurance is to leave the page. After you've deleted the login cookie, ...


1

Just like anti-virus identifies malware on your local machine - by checking for virus signatures. Although executable code cannot normally be ran through your web browser automatically, if there is a flaw in the browser or in a plugin such as Flash or Java, then the web page can exploit this to trigger a "drive by download". On example is this heap ...


0

HTML and JavaScript, when employed in specific ways, can be used to o wn your system, even your home router. The attack vectors against a web browser involve things like: malicious plugin files (mainly Flash, Silverlight) that exploit vulnerabilities in the plugin (Flash Player, Silverlight Player) JavaScript that exploits vulnerabilities in the browser's ...


3

Go to https://www.virustotal.com/ Put in the URL of the website you visited that gave you the JavaScript warning. It will search to see if that URL has malicious content. You will get results. Unless there is zero-day malware on that URL, the results will be correct.


1

Math.random() is not for crypto because it is not built for that: Returns a Number value with positive sign, greater than or equal to 0 but less than 1, chosen randomly or pseudo randomly with approximately uniform distribution over that range, using an implementation-dependent algorithm or strategy. This function takes no arguments. As far as prediction ...


18

While it is currently safe on Chrome you should not base your future checks on that. Things may change anytime and I have not seen the lack of rendering as being a specifically documented feature. If you want to look at the code, it is much better to download the page via a command-line tool (curl for instance) and analyze what was loaded and saved in a ...


29

Yes, it is absolutely safe (in Google Chrome) to open an untrusted website in view-source mode. The key point to note here is that you should "open" the page in view-source mode, meaning you should not allow any rendering to happen by normally loading the webpage first and then viewing the source. An example in Google Chrome would be ...


3

It is safe as everything on the client-side is, by definition, already accessible client-side. If you're worried about the password being exposed and read by passers by of the user's screen, then normal users will not have the console active. If they did, it would also be possible to see the password entered via the Network tab: Screenshot taken from ...


0

It is safe simply because even the least skilled attacker can simply add their own. And the java-script is only really knows what the end user already knows anyway. But on that note it is also poor programming practice to produce excessive console output.


7

No, stripping <script> tags is useless because you could still execute a javascript payload like this: <input onmouseover=prompt(document.cookie)> And bypassing the filter should also be quite easy, imagine what would happen if a payload like this sent: <scr<script>ipt> As far as what type of software they are using, well ...


0

Sometimes you get lucky and the app is built in a way that it will hold input state server side and reflect it back if it sees errors. This behavior may not be obvious by default because javascript validation may prevent you from ever seeing that postback (but it's added to make non-js browsers function). Try seeing if the input has a name parameter and ...


0

If u cant send the link, that would be a case of self-xss which involves the victim injecting malicious javascript snippets himself, which is a non-vulnerability in the bug bounties i have come across or even for professional assessments. However, social engineering attacks have been reported in the past wherein an attacker convinces someone to paste ...


1

An old question, but adding an answer for modern times. For sensitive responses, you should set the following header: Cache-Control: no-store, must-revalidate These days, you probably don't need to worry about the HTTP 1.0 Expires header. Pragma is only for requests, not responses. To refresh the page just after session timeout (so that the login form ...


1

I came up with the code below but it doesn't work That's because you are performing a CSRF attack, but in exercise 2.1 there is actually an anti-CSRF token preventing this. You have to exploit the XSS vulnerability here. I came up with a plan to use a cookie and set the token to 'abc'. So, when I come to login, i use the username and password that I ...


2

A source code disclosure vulnerability is an involuntary disclosure of source code. Since JavaScript code runs client-side, on the browser, it's disclosure is intentional. Under this definition, only exposure of the server-side code is a source code disclosure vulnerability. The example you give actually has the GPL on it, so it's already disclosed ...


4

That is the correct behavior. In the case of client-side JavaScript, it is by design that the script source is sent to the client to be executed. So, the fact that you can manually browse to the URL for the script file is irrelevant. It gives you no more access than the application intends for you to have. A source-code disclosure vulnerability is when ...


2

This cannot work as you envision. For one thing, web browsers are not the only thing that cause DNS lookups: anything (such as a network time client) that needs to convert domain names into IP addresses or vice-versa will do so. For another, you cannot count on the browser doing a DNS lookup every time it loads a page. The DNS resolver should cache the ...


1

Perhaps, as a start, use the Adblock domain list and block some of these domains which will prune some of the traffic.


2

Yes, all your assumptions are correct there. As you are including content from addthis.com, your client-side Origin is fully trusting this domain. If there was any compromise to addthis.com, or if addthis.com decided to change the script to do something more invasive then your site would be vulnerable. For example, addthis.com may suddenly decide they want ...



Top 50 recent answers are included